[solved] Clover: failing to patch kext's Info.plist, trying to disable X86PlatformPlugin.kext

[simmel]

Hello!

 

I have a Sandy Bridge CPU and I need ACPI power management. I'm on macOS 12.3.1. X86PlatformPlugin.kext now matches against IOACPIPlatformDevice only:

 

It was:

<key>IOParentMatch</key>
<dict>
	<key>IOPropertyMatch</key>
	<dict>
		<key>plugin-type</key>
		<integer>1</integer>
	</dict>
	<key>IOProviderClass</key>
	<string>IOACPIPlatformDevice</string>
</dict>

 Now it is:

<key>IOParentMatch</key>
<dict>
	<key>IOProviderClass</key>
	<string>IOACPIPlatformDevice</string>
</dict>

As a result, X86PlatformPlugin.kext is loaded and my CPU frequency is stuck. So my goal is to disable X86PlatformPlugin.kext. In Clover's config.plist I have:

<key>KernelAndKextPatches</key>
<dict>
	<key>KextsToPatch</key>
	<array>
		<dict> 
			<key>Comment</key>
			<string>disable X86PlatformPlugin.kext</string>
			<key>Disabled</key>
			<false/>  
			<key>Find</key>
			<data>QUNQSQ==</data>
			<key>InfoPlistPatch</key>
			<true/>
			<key>Name</key>
			<string>X86PlatformPlugin</string>
			<key>Replace</key>
			<data>WFhYWA==</data>
		</dict>
	</array>
</dict>

This should replace the string "ACPI" with "XXXX". However, it does not work. Bdmesg says:

4:084  0:000  Filtering KextPatches:
4:084  0:000   - [00]: X86PlatformPlugin (disable X86PlatformPlugin.kext) :: PlistPatch :: [OS: 12.3.1 | MatchOS: All | MatchBuild: All] ==> allowed
4:084  0:000  Will not patch boot.efi
4:084  0:000  Bridge X86PlatformPlugin patch to OC : X86PlatformPlugin (disable X86PlatformPlugin.kext)

Clover version is 5141. I don't know what's wrong. Any help is appreciated! Thank you!

Edited April 10, 2022 by simmel

[Guest 5T33Z0]

@simmel

Why don't you just use ssdtprgen to generate a SSDT-PM?

 

It sets X86Platform Plugin to 0 or tells the OS to use the legacy ACPI_SMC_PlatformPlugin and the provided Frequency data in the .aml instead.

 

 

Edited April 8, 2022 by 5T33Z0

[simmel]

Thanks for your reply! I already have a custom SSDT and it used to work fine. The problem seems to be that X86PlatformPlugin doesn't match against the plugin-type=0x1 device property anymore, which means it will always be loaded if IOACPIPlatformDevice is present. This is a new behavior since version 12.3 or 12.3.1. X86PlatformPlugin has a higher IOProbeScore (2000) than ACPI_SMC_PlatformPlugin (1000).

[simmel]

EDIT: Removed my reply to deleted posting.

 

@Sergey: Do you have an idea?

Edited April 8, 2022 by simmel

[Slice]

On 4/8/2022 at 8:08 PM, simmel said:

Thanks for your reply! I already have a custom SSDT and it used to work fine. The problem seems to be that X86PlatformPlugin doesn't match against the plugin-type=0x1 device property anymore, which means it will always be loaded if IOACPIPlatformDevice is present. This is a new behavior since version 12.3 or 12.3.1. X86PlatformPlugin has a higher IOProbeScore (2000) than ACPI_SMC_PlatformPlugin (1000).

OK, now I understood your problem. Wait a minute.

[Slice]

This is a common issue: InfoPlistPatching can't be used to DISABLE kext because if it will be disabled then nothing to patch. If it present then it is already non-patched.

I will propose to make Disabler but my attempt was failed.

May be you have an idea what to change to make this kext really working

X86PluginDisabler.kext.zip

Or make binary patch to the kext will not started.

[simmel]

Hello Sergey,

 

Thank you! Sadly, no luck so far. I added IOParentMatch to disabler kext but it didn't change anything. Clover kext patches I tried:

 

1) Replace first 8 bytes (mach-o header) of X86PlatformPlugin with zeros -> X86PlatformPlugin happily loads.

2) Rise IOProbeScore of ACPI_SMC_PlatformPlugin from 1000 to 9000 -> X86PlatformPlugin unimpressed.

3) For testing purpose I replaced "Microphone" in AppleHDA with "Telephone " (sic!), but I couldn't see any difference in audio preferences.

 

Is there a better way to check if a patch really get's applied? I fear that for some reason kext patching might be broken on my side. I updated to latest Clover yesterday, no difference between 5141 and 5146. Logs show that patches are bridged to OC.

<dict>
    <key>Comment</key>
    <string>Test</string>
    <key>Disabled</key>
    <false/>
    <key>Find</key>
    <data>TWljcm9waG9uZQ==</data>
    <key>InfoPlistPatch</key>
    <false/>
    <key>Name</key>
    <string>AppleHDA</string>
    <key>Replace</key>
    <data>VGVsZXBob25lIA==</data>
</dict>

 

EDIT: Finally success! OpenCore Legacy Patcher has a kext to solve the problem (attached below). From 0.4.3 Changelog:

- Add XCPM disabling
Forces ACPI_SMC_PlatformPlugin to outmatch X86PlatformPlugin

Now my good old Sandy Bridge hackintosh is perfect again!

ASPP-Override-v1.0.1.zip

Edited April 10, 2022 by simmel

[Slice]

4 hours ago, simmel said:

Hello Sergey,

 

Thank you! Sadly, no luck so far. I added IOParentMatch to disabler kext but it didn't change anything. Clover kext patches I tried:

 

1) Replace first 8 bytes (mach-o header) of X86PlatformPlugin with zeros -> X86PlatformPlugin happily loads.

2) Rise IOProbeScore of ACPI_SMC_PlatformPlugin from 1000 to 9000 -> X86PlatformPlugin unimpressed.

3) For testing purpose I replaced "Microphone" in AppleHDA with "Telephone " (sic!), but I couldn't see any difference in audio preferences.

 

Is there a better way to check if a patch really get's applied? I fear that for some reason kext patching might be broken on my side. I updated to latest Clover yesterday, no difference between 5141 and 5146. Logs show that patches are bridged to OC.

<dict>
    <key>Comment</key>
    <string>Test</string>
    <key>Disabled</key>
    <false/>
    <key>Find</key>
    <data>TWljcm9waG9uZQ==</data>
    <key>InfoPlistPatch</key>
    <false/>
    <key>Name</key>
    <string>AppleHDA</string>
    <key>Replace</key>
    <data>VGVsZXBob25lIA==</data>
</dict>

 

EDIT: Finally success! OpenCore Legacy Patcher has a kext to solve the problem (attached below). From 0.4.3 Changelog:

- Add XCPM disabling
Forces ACPI_SMC_PlatformPlugin to outmatch X86PlatformPlugin

Now my good old Sandy Bridge hackintosh is perfect again!

ASPP-Override-v1.0.1.zip 1.88 kB · 1 download

Just increasing IOProbeScore for the kext?

[simmel]

Yes. This is what this kext does. To me, it looks like Apple is going to remove ACPI_SMC_PlatformPlugin sooner or later.

[Slice]

5 hours ago, simmel said:

Yes. This is what this kext does. To me, it looks like Apple is going to remove ACPI_SMC_PlatformPlugin sooner or later.

It looks logical because Intel HD4000 graphics of IvyBridge already excluded from Monterey.

[Vinicius P. Miranda]

@simmel 

Can you explain to me how you got Power Management on Sandy Bridge for me to test on my Sandy Bridge-E?

I got PM on Monterey 12.3.1 with two patches from "com.apple.driver.AppleIntelCPUPowerManagement", and it doesn't need "ssdtprgen". But I saw that I lost a bit of single core performance with some benchmarks.

I'm looking to learn new ways to make PM work well to see if I can get the performance I lost back. About 20%.

[simmel]

I patched my Aptio BIOS to unlock MSR 0xE2 for native power management. I suggest to open a new thread for that. There are some good guides on the net, but it looks like there is another method I did not know, involving CFGLock.efi. Please be aware that trying to unlock MSR 0xE2 is dangerous and may leave your device in an unusuable state.

[Slice]

2 hours ago, simmel said:

I patched my Aptio BIOS to unlock MSR 0xE2 for native power management. I suggest to open a new thread for that. There are some good guides on the net, but it looks like there is another method I did not know, involving CFGLock.efi. Please be aware that trying to unlock MSR 0xE2 is dangerous and may leave your device in an unusuable state.

"Native" for Apple or for Zotac? Apple's power management especially C-states controlled by 0xE2 may not be appropriate for non-native hardware.

I will propose to set KernelPM=YES and AppleIntelCPUPM=YES and do not bother about locked 0xE2.

[simmel]

Well, I think it depends. I have made good expirience with unlocked MSR and custom DSDT and SSDT. I did it once many years ago and, despite of the issue above, I never had to worry about sleep, wake or CPU frequency scaling. Generally I prefer to avoid hotpatching because it is sometimes less reliable or needs to be adjusted from time to time. I'm a lazy person.