Great people share their wisdom without asking for anything in return…

Menu

XCPM for unsupported Processor…

The lack of XCPM support for my new Broadwell E processors was a bit frustrating and thus I had to do something about it. And I guess that most of you know me by now so it was just a matter of time. As in. Consider it done!

Yup. Time to say good-bye to the good old AppleIntelCPUPowerManagement.kext and the NullCPUPowerManagement.kext that served so many people for so long. Adieu my friends. They won’t be missed. LOL

Right. I can boot macOS Sierra and I see IOPPF: XCPM mode along with XCPM registered. That is pretty cool. In fact. This is amazing. Let’s go check some stuff.

sysctl -n machdep.xcpm.mode returns 1 so that is fine. Also. Running kextstat shows me that both AppleIntelCPUPowerManagement.kext and NullCPUPowerManagement.kext are missing in the list with loaded kexts. Great. Now a Geekbench v3.4.1 top score – one of four runs – of the Intel i7-6850K.

I must admit. The longer I use this processor the more I get impressed by it. Who would have thought that? And let’s not forget. This is with XCPM so it is the more impressive. In fact. People with an old i7-5930K may keep it.

One thing though and that is that the RAM can’t run at full speed (runs like 2133MHz due to some bug) but anyway. Here is the output of AppleIntelInfo.kext

Hmm. C3 is missing. Seems like I forgot to enable C3 for Broadwell E processors and thus I have to fix this and re-compile the kext. On a second thought. The redirection bits are not set in MSR 0xE2 so this is expected result.

But both MSR_PKG_C2_RESIDENCY and MSR_PKG_C6_RESIDENCY are non-zero. A sweet spot.

Update: I don’t have a lot of time, but I also do not want to let you wait so here you have it!

Update: DP4 is now available and the byte patterns are still the same, but the locations have changed to: 0x1f8d81, 0x227d32, 0x21e440, 0x21e46f and 0x228130 (same order as above).

Update-2: DP5 is now available and the byte patterns are still the same, but the locations have changed to: 0x1f8930, 0x228af0, 0x21eff0, 0x21f01f and 0x228f50 (same order as above).

Update-3: DP6 is now available and the byte patterns are still the same, but the locations have changed to: 0x1f7cc0, 0x227f30, 0x21e430, 0x21e45f and 0x428390 (same order as above).

Update-4: DP7 is now available and the byte patterns are still the same, but the locations have changed to: 0x1f8d71, 0x227fc2, 0x21e460, 0x21e48f and 0x2283c0 (same order as above).

The patches can be done in at least three different ways and I picked what I think is the easiest one to understand. So I hope. Also. I don’t use FakeCPUID – nor Clover for that matter – with my patches, but some people using Clover reported a hang. For them it won’t boot without FakeCPUID (thanks to giacomoleopardo for the update).

Update: Owners of Ivy Bridge E or Haswell E processors do not need to patch the switch table used by _cpuid_set_info, because Apple already took care of it. Anyway. Have a look at this table:

The offset for the Broadwell E processor is missing in this table. There is an address but that jumps to a location for unsupported processors, which is why we need a patch for the Broadwell E processor (the red arrow shows you what we do with the patch) but I think that Apple will fix this with a future update of macOS Sierra so that we also no longer need to patch the table for Broadwell E processors.

Please note that the table was converted from the original one in the kernel, which looks like this:

Update: DP4 is now available and while the table is still the same, the location of it has changed to: 0xffffff8000427e9c

Update: DP7 is now available and while the table is still the same, the location of it has changed to: 0xffffff800042812c

A shorter table with 34 instead of 72 values, but the idea here is the same. And with the same kind of table conversion we get this:

This time the table starts at 0x3c instead of 0x17 and there are no addresses for the Ivy Bridge E, Haswell E and Broadwell E processors, again, for the same reason; it jumps to a location for processors that do not support XCPM.

Speaking about that address. All locations in the switch table in the kernel with the value 0xfffffeb8 jump to the same location for unsupported processors and here is how to calculate the offset and target address for the jmp instruction:

This routine has no matching case number for the Ivy Bridge E, Haswell E and Broadwell E processors. That is why we lower the model number to make it match with a supported processors model. Like we are using a normal Ivy Bridge, Haswell or Broadwell processor. A simple but effective trick it seems.

I hope that my explanation about all this helps you to understand what we are doing.

Edit: Make sure that you either use a SMBIOS model/board-id with FrequencyVectors data in its plist, or patch it with help of freqVectorsEdit.sh v2.3.

You can verify that the FrequencyVector data is loaded with help of sysctl -n machdep.xcpm.vectors_loaded_count

Tips:

1.) The X86PlatformPlugin.kext will only load with the plugin-type property is set on the first logical CPU. This however is not enough to enable XCPM mode. No. You may still use AppleIntelCPUPowerManagement.kext Even when X86PlatformShim.kext is loaded.

2.) The FrequencyVectors data in the plist is used to configure power management, and is not the same for all models/board-ids. Please use one that works for your setup.

3.) If sysctl -n machdep.xcpm.vectors_loaded_count returns 0 then the FrequencyVectors data is not being used. Backup the plist for your board-id and replace it with a different plist.

4.) If you use ssdtPRGen.sh to generate your ssdt_pr.aml then make sure to use the -turbo [top-turbo-frequency] argument for overclocked setups.

5.) Check for XCPM related errors at boot time. Like this: X86PlatformShim::start – Failed to send stepper. You got to fix errors or things may not work properly.

TODOs:

1.) Fix LFM frequency (fixed to 800MHz).2.) Figure out what MSRs trigger a reboot and only block them. Not all other supported MSRs as well.

Post navigation

450 thoughts on “XCPM for unsupported Processor…”

Comment navigation

Pike, how are you doing? Hope everything is fine over there!
Please, I really need your urgent help…. I can compile the source code for AppleIntelInfo.kext without any issues with Xcode 9 under macOS 10.13 and 10.12.6.

However when performing the kextload of AppleIntelInfo.kext, my Skylake-X/X299 System immediately reboots! I use the i9-7980XE and a ASUS Prime X299 Deluxe mobo.

I don’t know what is the source if this reboot, it might be Xcode 9 but I rather suspect that the current version of AppleIntelInfo.kext is incompatible with the i9-7980XE…

Can you please check on the issue and asap provide a modified version of AppleIntelInfo.kext on Github, if possible?

Ah yes. I do happen to have an update for that somewhere, but I cannot find it right now, and I don’t have a lot of time – I promised to help my wife I the garden. What you can do is to check the MSR’s with some other tool that lets you read them. Sorry. I forgot the name of it. Slice should know. He loves it 😉

Best regards to your wife, Pike! 🙂 please as soon you find time upload the modified version of AppleIntelInfo.kext, ok? Maybe you’ll find it in your garden? 🙂 I will just wait! I am totally a fan and freak of it and I need it‘s depictive output for my guide development! Don’t wanna miss it!!!