aben Posted May 12, 2022 Share Posted May 12, 2022 (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. UPDATE: macOS 12.3 drops "plugin-type" check during CPU probe (X86PPlugin now attaches natively by default for XCPM CPUs), which now leads to pre-Haswell CPUs (trash can: MacPro6,1) failing to otherwise attach to legacy-companion ACPI_SMC_PlatformPlugin for CPU-power-management duties under normal conditions (macOS 12.2); this means pre-Haswell loses native CPU power management moving forward (macOS 12.3 and up) Edited March 22, 2023 by aben Update and thx to etorix for spotting the error. 5 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted May 12, 2022 Share Posted May 12, 2022 (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 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 May 12, 2022 by 5T33Z0 Link to comment Share on other sites More sharing options...
miliuco Posted May 12, 2022 Share Posted May 12, 2022 Same here. SSDT-PLUG disabled in config.plist. Thanks @aben for the information that I was completely unaware of. Spoiler 3 Link to comment Share on other sites More sharing options...
rafale77 Posted May 12, 2022 Share Posted May 12, 2022 Will test this ASAP and will report back. Very interesting indeed! Link to comment Share on other sites More sharing options...
xtddd Posted May 13, 2022 Share Posted May 13, 2022 good news Link to comment Share on other sites More sharing options...
aben Posted May 13, 2022 Author Share Posted May 13, 2022 (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 May 13, 2022 by aben Added info regarding OCLP 2 Link to comment Share on other sites More sharing options...
etorix Posted May 13, 2022 Share Posted May 13, 2022 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). 3 1 Link to comment Share on other sites More sharing options...
miliuco Posted May 13, 2022 Share Posted May 13, 2022 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. 2 Link to comment Share on other sites More sharing options...
aben Posted May 14, 2022 Author Share Posted May 14, 2022 (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 May 16, 2022 by aben typo 2 Link to comment Share on other sites More sharing options...
hardcorehenry Posted August 12, 2022 Share Posted August 12, 2022 (edited) On 5/14/2022 at 6:10 AM, aben said: 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 About that, MEM2 doesn’t seem to be some exotic device only present in Mac, in my AsusH81M-E there is native MEM2 in OEM ACPI(SSDT-SaSsdt precisely), but it doesn’t appear in IOReg because _STA needs some conditions(very easy to make little SSDT-hot-patch to enable it, though). Unfortunately I also don’t know a purpose of this device and if it’s worth/safe enabling it. Spoiler Edited August 12, 2022 by hardcorehenry 1 Link to comment Share on other sites More sharing options...
Recommended Posts