OcAppleKernelLib: Add builtin XCPM patches for Ivy Bridge and other unsupported CPUs

[PMheart]

Background

Owing to the lack of symbol resolver and bitmasking, @syscl and I created a tremendous number of patches in Clover years ago, which conversely helps us cope with the bytes nowadays despite messy. There @syscl (or I) added patches earlier than 10.12 as well, yet it has not been well tested. (Or rather NOT AT ALL!) I think the first time people started this heated debate was by the time @Piker-Alpha posted his (probably the first detailed) article at his blog.
And now with OC, it would be nice to handle this much more properly.

What to patch

As summed up at InsanelyMac, XCPM on unsupported CPUs requires several patches:

• Function wise: _cpuid_set_info(), _xcpm_bootstrap() (functional with our CPUID patch, as of acidanthera/OcSupportPkg@98ef065)
• MSR wise: _xcpm_SMT_scope_msrs (DONE at acidanthera/OcSupportPkg@2366b81), _xcpm_core_scope_msrs (DONE at PatchAppleXcpmCfgLock() a long time ago) and _xcpm_pkg_scope_msrs (DONE at acidanthera/OcSupportPkg@4e916c6) under function _xcpm_init()
• Certain Skylake+ with HWP needs patches applied to _xcpm_idle(). (functional as of acidanthera/OcSupportPkg@b2b0fa3)
• Low-end Haswell+ Celeron and Pentium needs AVX patch in addition. (NO SUPPORT! See NOTES below for Haswell+ low-end)
• Performance fix for certain high-end models, although the current implementation does not seem sane. (See NOTES below for performance fix)

Special NOTES for Haswell+ low-end

Your support gets dropped as of 10.13 or 10.14 kindly by Apple. Sorry, I cannot tell the exact version, but it indeed is bad news. Well, I will be able to post the necessary patches if you just want to try out earlier versions with your lovely low-end models. LOL
First, apply CPUID patch via Kernel->Emulate:

Cpuid1Data: <A9 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00>
Cpuid1Mask: <FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00>

This will fake CPUID as 0x306A9 (Ivy Bridge) in order to successfully boot. Yet Ivy Bridge is an XCPM-unsupported model, thus patch to _xcpm_bootstrap might be needed depending on macOS version, as well as a universal patch for AVX (see below):

• For 10.11 and older, just apply the CPUID patch above and simply accompanied by boot-arg named -xcpm.
• For 10.12 and newer, please apply whichever fitting macOS version in addition to the CPUID patch above:

_xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.12

Base: _xcpm_bootstrap
Comment: _xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.12
Count: 1
Enabled: YES
Find: C4830022
Identifier: kernel
Limit: 0
Mask: FFFF00FF
MatchKernel: 16.
Replace: C6830022
ReplaceMask: FFFF00FF
Skip: 0

_xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.13+ (10.13-10.15 at least)

Base: _xcpm_bootstrap
Comment: _xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.13+
Count: 1
Enabled: YES
Find: 00C43C22
Identifier: kernel
Limit: 0
Mask: 00FFFFFF
MatchKernel: 16.
Replace: 00C63C22
ReplaceMask: 00FFFFFF
Skip: 0

As well as this universal AVX patch for 10.12+:

Base: [EMPTY]
Comment: Haswell+ low-end Celeron/Pentium cpuid_set_info_rdmsr (c) vit9696
Count: 1
Enabled: YES
Find: B9A00100000F32
Identifier: kernel
Limit: 0
Mask: [EMPTY]
MatchKernel: [EMPTY]
Replace: B9A001000031C0
ReplaceMask: [EMPTY]
Skip: 0

Special NOTES for performance fix

Firstly. Do NOT use this patch whenever possible! It basically even breaks the idea of CPU power management. Secondly, it is named AppleXcpmForceBoost in OpenCore quirks.

Legacy patch depending on macOS version

XCPM performance fix (10.8.5 - 10.13.3)

Base: [EMPTY]
Comment: XCPM performance fix (c) okrasit 10.8.5 - 10.13.3
Count: 0
Enabled: YES
Find: 89D8C1E0 08000000
Identifier: kernel
Limit: 0
Mask: FFFFFFFF FF000000
MatchKernel: [EMPTY]
Replace: B800FF00 00000000
ReplaceMask: FFFFFFFF FF000000
Skip: 0

XCPM performance fix (10.13.4+)

Base: [EMPTY]
Comment: XCPM performance fix (c) okrasit & vit9696 10.13.4+
Count: 0
Enabled: YES
Find: C1E3084863D389D048C1EA20B99901
Identifier: kernel
Limit: 0
Mask: [EMPTY]
MatchKernel: [EMPTY]
Replace: C1E308B800FF000031D29090B99901
ReplaceMask: [EMPTY]
Skip: 0

[PMheart]

Done with both necessary code in OpenCore and sufficient notes for special cases.

[mrmiller]

I'm adding this here because it seems, at least on the surface, related to some of these other patches.

I can't boot with the native CPUID for my Xeon Gold (0x050654) but using an emulated CPUID (0x0506E3/4) causes a kernel panic when or'ing 0x40 into MSR_MISC_PWR_MGMT (MSR 0x1aa). The issue is not present with other older CPUIDs, presumably because they don't support HWP. I can NOP out the wrmsr instruction in xcpm_cpu_control and boot fine. Is there some sort of write control or BIOS setting protecting this MSR? Or is 0x40 an illegal value for the CPU? As best I can tell, 0x40 seems to like it may be enabling SpeedShift.

I also need the above patches in AppleXcpmExtraMsrs to boot.

[vit9696]

@mrmiller bit 0 of that MSR is similar to CFG Lock (E2h MSR), but it might be unlockable from ring 0 (not just SMM like E2h). See the docs description:

EIST Hardware Coordination Disable (R/W)
When 0, enables hardware coordination of Enhanced
Intel Speedstep Technology request from processor
cores. When 1, disables hardware coordination of
Enhanced Intel Speedstep Technology requests.

Most likely Intel EIST is disabled in your firmware, but macOS expects that it is enabled. Your choice is either fix your firmware, or reset bit 0 on boot (if possible), or patch that MSR write.

[nms42]

Most likely Intel EIST is disabled in your firmware, but macOS expects that it is enabled. Your choice is either fix your firmware, or reset bit 0 on boot (if possible), or patch that MSR write.

Is it possible to add verification of that bit to VerifyMsrE2? Just to keep all relevant checks in one tool.

[vit9696]

No, it cannot be done reliably due to MSR desync on many GA boards (see VerifyMsrE2 for reference). Even if it was not the case, we would also not have bothered with detection as it does not follow OpenCore design. Closing again.

[mrmiller]

Most likely Intel EIST is disabled in your firmware, but macOS expects that it is enabled. Your choice is either fix your firmware, or reset bit 0 on boot (if possible), or patch that MSR write.

Bit 0 is indeed unset. I'll see if I can find a way to set it.

Which documentation are you referencing, by the way? I was looking for information about the MSR but couldn't find it in either Skylake-SP reference.

[vit9696]

Hmm, I expected it to be 0 to work… Maybe I am wrong. This is from sdm-vol-1-2abcd-3abcd.pdf. Table 2-15. MSRs in Processors Based on Intel® Microarchitecture Code Name Nehalem (Contd.); Vol. 4 2-127. MSRs are usually better explained in SDM, although it is all a bit messed up.

[mrmiller]

Hmm, I expected it to be 0 to work… Maybe I am wrong. This is from sdm-vol-1-2abcd-3abcd.pdf. Table 2-15. MSRs in Processors Based on Intel® Microarchitecture Code Name Nehalem (Contd.); Vol. 4 2-127. MSRs are usually better explained in SDM, although it is all a bit messed up.

Ah, sorry! I misunderstood what you said and had it backwards.

Documentation is rather light there. I don't really get the sense that bit 0 is a lock on the rest of the bits either.

Here's my current state for that MSR:

MSR_MISC_PWR_MGMT................(0x1AA) : 0x403040
------------------------------------------
 - EIST Hardware Coordination........... : 0 (hardware coordination enabled)
 - Energy/Performance Bias support...... : 1
 - Energy/Performance Bias.............. : 0 (disabled/MSR not visible to software)
 - Thermal Interrupt Coordination Enable : 1 (thermal interrupt routed to all cores)
 - SpeedShift Technology Enable......... : 1 (enabled)
 - SpeedShift Interrupt Coordination.... : 0 (disabled)
 - SpeedShift Energy Efficient Perf..... : 1 (enabled)
 - SpeedShift Technology Setup for HWP.. : Yes (setup for HWP)

What's curious to me is that the kernel is trying to or 0x40 into the MSR, which is clearly a valid value because it's already set to that. That implies to me that there's some sort of write protection on the MSR which causes the fault.

[vit9696]

Yes, you are most likely right.

macOS wants to have full control on Intel Power Management technologies available, and our firmware tries to implement EIST, HWP, and friends support for everyone else but macOS. Sometimes related registers are available for writing (like MSR_FLEX_RATIO), sometimes they are locked (like PKG_CST_CONFIG_CONTROL aka E2h or CFG Lock) till the next reboot.

It is like an infinite trouble area but in general you could find some firmware preferences to disable this or that, and macOS can live happily. The documentation is indeed quite opaque, but I e-mailed you some materials that may help.

[Halelluja12]

Background

Owing to the lack of symbol resolver and bitmasking, @syscl and I created a tremendous number of patches in Clover years ago, which conversely helps us cope with the bytes nowadays despite messy. There @syscl (or I) added patches earlier than 10.12 as well, yet it has not been well tested. (Or rather NOT AT ALL!) I think the first time people started this heated debate was by the time @Piker-Alpha posted his (probably the first detailed) article at his blog.
And now with OC, it would be nice to handle this much more properly.

What to patch

As summed up at InsanelyMac, XCPM on unsupported CPUs requires several patches:

• Function wise: _cpuid_set_info(), _xcpm_bootstrap() (functional with our CPUID patch, as of acidanthera/OcSupportPkg@98ef065)
• MSR wise: _xcpm_SMT_scope_msrs (DONE at acidanthera/OcSupportPkg@2366b81), _xcpm_core_scope_msrs (DONE at PatchAppleXcpmCfgLock() a long time ago) and _xcpm_pkg_scope_msrs (DONE at acidanthera/OcSupportPkg@4e916c6) under function _xcpm_init()
• Certain Skylake+ with HWP needs patches applied to _xcpm_idle(). (functional as of acidanthera/OcSupportPkg@b2b0fa3)
• Low-end Haswell+ Celeron and Pentium needs AVX patch in addition. (NO SUPPORT! See NOTES below for Haswell+ low-end)
• Performance fix for certain high-end models, although the current implementation does not seem sane. (See NOTES below for performance fix)

Special NOTES for Haswell+ low-end

Your support gets dropped as of 10.13 or 10.14 kindly by Apple. Sorry, I cannot tell the exact version, but it indeed is bad news. Well, I will be able to post the necessary patches if you just want to try out earlier versions with your lovely low-end models. LOL
First, apply CPUID patch via Kernel->Emulate:

Cpuid1Data: <A9 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00>
Cpuid1Mask: <FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00>

This will fake CPUID as 0x306A9 (Ivy Bridge) in order to successfully boot. Yet Ivy Bridge is an XCPM-unsupported model, thus patch to _xcpm_bootstrap might be needed depending on macOS version, as well as a universal patch for AVX (see below):

• For 10.11 and older, just apply the CPUID patch above and simply accompanied by boot-arg named -xcpm.
• For 10.12 and newer, please apply whichever fitting macOS version in addition to the CPUID patch above:

_xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.12

Base: _xcpm_bootstrap
Comment: _xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.12
Count: 1
Enabled: YES
Find: C4830022
Identifier: kernel
Limit: 0
Mask: FFFF00FF
MatchKernel: 16.
Replace: C6830022
ReplaceMask: FFFF00FF
Skip: 0

_xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.13+ (10.13-10.15 at least)

Base: _xcpm_bootstrap
Comment: _xcpm_bootstrap (Haswell+ low-end Celeron/Pentium) 10.13+
Count: 1
Enabled: YES
Find: 00C43C22
Identifier: kernel
Limit: 0
Mask: 00FFFFFF
MatchKernel: 16.
Replace: 00C63C22
ReplaceMask: 00FFFFFF
Skip: 0

As well as this universal AVX patch for 10.12+:

Base: [EMPTY]
Comment: Haswell+ low-end Celeron/Pentium cpuid_set_info_rdmsr (c) vit9696
Count: 1
Enabled: YES
Find: B9A00100000F32
Identifier: kernel
Limit: 0
Mask: [EMPTY]
MatchKernel: [EMPTY]
Replace: B9A001000031C0
ReplaceMask: [EMPTY]
Skip: 0

Special NOTES for performance fix

Firstly. Do NOT use this patch whenever possible! It basically even breaks the idea of CPU power management. Secondly, it is named AppleXcpmForceBoost in OpenCore quirks.

Legacy patch depending on macOS version

thank u so much

[startergo]

If I want to emulate XSAVE, XSAVEC and XSAVEOPT how should I set the CPUID1Data:

[startergo]

Sorted out ECX features spoofing:
https://forums.macrumors.com/threads/understanding-the-opencore-data-variable-settings.2236028/post-29152949
How is OC modifying the CPUID as MacCPUID does not see the spoof?
https://forums.macrumors.com/threads/understanding-the-opencore-data-variable-settings.2236028/post-29153977

[th0u]

Hello,
I came across this Issue reading OpenCore Documentation regarding AppleXcpmExtraMsrs because I have the issue that on my Gigabyte B360 DH3 + i7-9700K the CPU did not boost beyond 3,7GHz until AppleXcpmExtraMsrs was enabled. AppleCpuPmCfgLock is off as the board allows CFG Lock disable. I tested unter macOS 10.15 and 11.1.

As I have dual boot to win10, I was able to verify that this combo can really boost to 4.9Ghz.

Basically the (latest rev of Board) Bios is setup according OpenCore Setup Guide for Coffee Lake. I tried also different Settings in Bios regarding Speed Step and so on without success in regards of CPU Boost. Also I tested several hints regarding SSDT-Plug or CPUFriend.

So finally, after enabling AppleXcpmExtraMsrs, my i7-9700K boosts beyond 3,7Ghz.

Cheers, T

[vit9696]

@th0u I believe the issue might be in your BIOS settings, but good to hear that you found a workaround anyway.

[lightCruiser007]

I'm a newbie to this field. Can someone tell me what, where and how to patch?