Jump to content

macOS 12 Monterey: x86PlatformPlugin without plugin-type=1?


aben
 Share

9 posts in this topic

Recommended Posts

Posted (edited)

Since I have not seen any reports elsewhere and as the title suggests, it looks like macOS 12 now appears to load x86PlatformPlugin natively without the need for the good old injection of plugin-type=1 (SSDT-PLUG patch)? Even attaching to the correct CPU defined within the ACPI table natively. Have I missed something with regards to such changes in macOS 12? Is this behavior now possibly SMBIOS dependent or are we seeing a depreciation of ACPI_SMC_PlatformPlugin starting from macOS 12 even though it’s presence is seen? (Big Sur does load legacy ACPI_SMC_PlatformPlugin, as expected, when using the same Skylake system booting off the same EFI without the patch) Anyone else confirm this behavior?
 

If this means Haswell and above now have native power management on macOS 12 (x86PlatformPlugin loaded by default) without the need for SSDT-PLUG / plugin-type=1 injection, that's real good news; one less unnecessary patch moving forward.

 

image.png.4744f6204b623ba5861999e34d5da679.png

 

UPDATEIt has been confirmed that macOS 12.3 dropped the "plugin-type" check within x89PlatformPlugin which now leads to legacy ACPI_SMC_PlatformPlugin failing to attach to the CPU in otherwise normal conditions. OpenCore developers are also confirming this to be an apparent bug from Apple's end as this supposedly breaks power management on pre-Ivy Bridge systems however this statement really doesn't make sense since macOS 12 never had native support for Ivy-Bridge and earlier. 

Edited by aben
Added screenshot for reference
  • Like 5
  • Thanks 1
Link to comment
Share on other sites

  • aben changed the title to macOS 12 Monterey: x86PlatformPlugin without plugin-type=1?
Posted (edited)

That's interesting. I never tested this. I will check it out and report back. What are your system specs?

 

EDIT: I can confirm that on my 10th Gen Core i9, I don't need SSDT-PLUG under macOS Monterey 12.4

 

i9_10thGen.thumb.png.a05c3f43e85af877958d6496ca4c112f.png

 

In macOS Big Sur it's still required. I think having a Min Kernel/ Max Kernel feature for ACPI tables would be a nice to have feature now. But thinking abut it, I guess that's impossible, since ACPI works on a lower level.

Edited by 5T33Z0
  • Thanks 1
Link to comment
Share on other sites

Posted (edited)
13 hours ago, miliuco said:

Same here. SSDT-PLUG disabled in config.plist. Thanks @aben for the information that I was completely unaware of.


Thanks for testing and reporting @miliuco. TBH, I actually stumbled upon this behavior while I was in the midst of testing customized CPU frequency-vectors with help of CPUFriend, for quite sometime now, starting from a few macOS 12 builds prior. At first, I completely overlooked this as I was under the false impression that CPUFriendDataProvider.kext could possibly be injecting plugin-type=1 without the need for SSDT-PLUG (X86PlatformPlugin was clearly loading without the SSDT patch) but then I happened to review the documentation again and it clearly states SSDT-PLUG is a must for ACPI level injection of plugin-type=1 when opting for the kext route; which is when it actually struck me and the discovery did take me by surprise. Hence the reason for me to share my findings on the forum since I had not come across any reports or information yet regarding this possible massive change to power management on macOS 12 which was kinda baffling.

However, it looks like this discovery was indeed documented under OpenCore Legacy Patcher. Further information was shared with regards to this behavior on macOS 12: confirmed and documented by OpenCore developer Mykola Grymalyuk aka khronokernel here: https://github.com/acidanthera/bugtracker/issues/2013

As per his statement, this behavior appears to be a bug from Apple's end as it breaks power management on pre-Ivy Bridge CPUs on macOS 12 (due to breakage of legacy ACPI_SMC_PlatformPlugin) but this statement does not make any technical sense to me since macOS 12 was never designed with the intention to provide native power management for Ivy-Bridge and earlier CPUs in the first place or am I missing some context here that I'm not aware of? Maybe someone here can help shed further light on that. I think the developer is probably calling it a "bug" from OCLP's point of view.

I strongly believe this a sign that Apple is indeed finally planning to fully deprecate legacy ACPI_SMC_PlatformPlugin for good this time with the upcoming macOS 13 release. I see no reason for its existence anyways since support for Ivy-Bridge and earlier systems were officially dropped with macOS 12 announcement. WWDC is right around the corner so let's wait and see.

Edited by aben
Added info regarding OCLP
  • Like 2
Link to comment
Share on other sites

6 hours ago, aben said:

However, it looks like this discovery was indeed documented under OpenCore Legacy Patcher. Further information was shared with regards to this behavior on macOS 12: confirmed and documented by OpenCore developer Mykola Grymalyuk aka khronokernel here: https://github.com/acidanthera/bugtracker/issues/2013

As per his statement, this behavior appears to be a bug from Apple's end as it breaks power management on pre-Ivy Bridge CPUs on macOS 12 (due to breakage of legacy ACPI_SMC_PlatformPlugin) but this statement does not make any technical sense to me since macOS 12 was never designed with the intention to provide native power management for Ivy-Bridge and earlier CPUs in the first place or am I missing some context here that I'm not aware of? Maybe someone here can help shed further light on that.

Reading carefully, khronokernel does not describe this new behaviour as a bug but as a "bug" (note the quotes!), in response to the original poster who himself used this terminology—with the quotes. So it is definitively not a bug-without-quotes.

 

This looks more like a deliberate change from Apple to streamline power management, as macOS no longer supports pre-Ivy Bridge CPUs. Of course, this is a complication for OCLP but Apple has no obligation to support OCLP (and I would refrain from jumping to the paranoid conclusion that this was purposefully designed to break OCLP…).

 

Operative summary:

If an Intel hack is intended to run macOS 12.3 and later AND one assumes that Apple will not revert its decision, one can now omit SSDT-PLUG. But there's no need to omit SSDT-PLUG, and no drawback to keeping it.

Let me add that Alder Lake builds (and later) still require SSDT-PLUG-ALT (or SSDT-CPUR-Z690, but then possibly without SSDT-PLUG).

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Thanks @aben and @etorix for the info.

Following Etorix summary, i will keep using SSDT-PLUG since it seems that there is no problem doing it, just in case Apple reverses this behavior.

  • Like 2
Link to comment
Share on other sites

Posted (edited)
On 5/13/2022 at 11:55 PM, miliuco said:

Following Etorix summary, i will keep using SSDT-PLUG since it seems that there is no problem doing it, just in case Apple reverses this behavior.


Of course, as Etorix clarified, there is no drawback or issues with keeping SSDT-PLUG since real Macs actually have plugin-type=1 present in their ACPI tables, however, using this logic, there also shouldn't be an issue with adding a SSDT to inject a device like MEM2 for eg, which is found in ACPI tables of real Macs but has no functional benefit for a hackintosh except for cosmetic purposes. I believe the same can be said about Intel's HPET as well; although HPET is present in ACPI tables of Intel based Macs, modern macOS versions don't seem to require Intel's HPET; this can be seen in IOREG extracts of Intel based Macs (post Ivy-Bridge) running latest macOS with HPET missing, hackintosh systems too have shown to handle macOS just fine with HPET disabled in BIOS.

With that being said, and given the fact that macOS 12.3 has now dropped the "plugin-type" check in X86PlatformPlugin, keeping SSDT-PLUG to have "plugin-type=1" injected is looking more like a cosmetic factor now with respect to a hackintosh but of course this choice is solely up to the user.

Edited by aben
typo
  • Like 2
Link to comment
Share on other sites

 Share

×
×
  • Create New...