NullCPUPowerManagement 禁用CPU电源管理驱动
-
在非 Apple 硬件(虚拟或其他)上运行的 OS X 的另一个问题是 AppleIntelCPUPowerManagement 内核扩展,该内核扩展可能会导致计算机死机或向控制台发出有关 HPET 及其与 CPU 的关系的无尽调试消息。
在虚拟环境中,访客 OS 确实不需要更改处理器 C 状态。只需发出暂停指令的内置代码就足够了。此外,虚拟器可能希望仅实现足够的 HPET 来通过 xnu 启动例程,而不实际使 HPET 工作。
NullCPUPowerManagement 的作用是在 IOKit 服务注册过程中发挥一些技巧,以确保它接管其 IOResources 提供程序 nub 上的AppleIntelCPUPowerManagement 匹配类别。诀窍在于,与 IOResources nub 匹配的任何 nub 必须具有与其 IOMatchCategory 属性值相同的名称。默认情况下,nub 名称是其 IOClass 属性的值,该属性必须是其 C++ 类名称,而不应该是 AppleIntelCPUPowerManagement。为什么不?因为内核无法加载两个具有相同名称的 C++ 类。发生这种情况时,一个或另一个将获胜。在最好的情况下,我们的副本将获胜。但是在最坏的情况下,真正的 AppleIntelCPUPowerManagement 获胜,从而造成负载并造成严重破坏,这正是我们试图避免的事情。
因此,我们使用了自己的 C++ 类名,但随后从 init 方法中检索了 IOMatchCategory 键的值,并调用 setName 来设置要匹配的 nub 名称。结合 100 的探测分数,我们保证我们的提供商(IOResources)将选择我们而不是 Apple 的 kext。理想情况下,我们将实现一个主动探测方法,该方法会进行一些检查以查看系统是否能够使用 AppleIntelCPUPowerManagement。不幸的是,很难确切知道必须满足哪些条件。因此,除非您在命令行上通过 -allowAppleCPUPM,否则该版本(r11)始终会成功执行其探测,在这种情况下,它将使它的探测失败,从而使 AppleIntelCPUPowerManagement 附加。
该选项不能保证存在,它更多是用于调试目的,因此在尝试使 Apple 的 CPU PM 工作时,可以将 NullCPUPowerManagement kext 保留在 Extensions 文件夹中。万一您做对了,可以从引导标志中删除 -allowAppleCPUPM,您仍然可以引导系统。
项目:https://github.com/corpnewt/NullCPUPowerManagement
下载:https://github.com/corpnewt/NullCPUPowerManagement/archive/master.zip
https://loadream.lanzouo.com/iIhqjde7mgh