在非 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
