如何使用 PSCI 接口以 Hyp/EL2 模式启动内核？
How PSCI interface can be used to boot kernel in Hyp/EL2 mode?
我正在尝试了解如何使用 U-boot PSCI 接口将内核引导至 HYP 模式。
通过 u-boot 源代码，我确实看到有一个通用 psci.S 和其他 psci.S 是板特定的并且有以下疑问。
1). psci.S 如何以及在何处适合正常的 u-boot 流程（启动 u-boot 时何时以及如何调用 cpu_on 和 cpu_off 等 psci 服务）。s
2). u-boot的这个psci接口是如何用来在HYP模式下启动内核的（psci接口中有什么可以让Linux内核在HYP模式下启动）？
1). How and where psci.S fits in normal u-boot flow
U-boot 留出一些安全世界内存并在那里复制保护监视器代码，以便它可以在 U-Boot 退出后保持驻留并提供对一些 PSCI SMC 调用的最小处理。
(when and how psci service like cpu_on and cpu_off is called while booting u-boot)
他们不是。 U-Boot 仅在主 CPU 上运行并移交给 Linux。 Linux 可能会在其自己的引导过程中稍后启动辅助内核，但 U-Boot 早已不复存在，除了上述安全监视器代码。
2). How this psci interface of u-boot is used to boot kernel in HYP mode
不是。
(what is it in psci interface that allow Linux kernel to booted in HYP mode)?
没有。
您提到的补丁系列背后的要点是，对于 32 位 ARM 平台来说，具有 TrustZone 感知硬件设计但垃圾软件支持的情况太普遍了（不幸的是现在仍然如此）。供应商 BSP 实现了足够的引导加载程序来启动它，并且从不从引导中切换出安全 SVC 模式，因此整个 Linux 在安全世界中运行，并且它们的内核充满了高度特定于平台的代码直接戳像电源控制器这样的安全硬件。如果您想使用虚拟化，这会带来问题（如果您是 KVM/ARM 的共同维护者并且最近给自己买了一辆 CubieTruck，这显然是一个紧迫的问题......） - 很容易采取此类平台的 U-boot 代码并使其在启动前切换到 NS-HYP Linux，从而启用 KVM（当时上游 U-boot 已经对此提供了一些基本支持），但是一旦你放弃了在安全世界之外，您以后无法使用依赖于仅安全硬件的原始 smp_operations 来启动您的辅助 CPU。
通过实现一些琐碎的运行时 "firmware" 挂在引导加载程序的后面，然后您可以根据需要以最简单的方式回调到安全世界，并且移动必要的平台是最有意义的- 那里的特定代码将操作抽象到一个简单的固件调用接口后面，特别是如果Linux已经有一个合适的支持。
PSCI 本身绝对没有什么特别之处 - 有许多 ARM 平台具有适当的安全固件，它们通过它们自己的专有协议实现电源管理和 SMP 操作。唯一模糊相关的方面是符合 PSCI 规范保证所有 CPU 将以相同模式出现，因此如果您最初在 HYP 中输入 Linux，您将不会看到不匹配的辅助节点出现在其他一些不兼容的模式或安全状态中。
我正在尝试了解如何使用 U-boot PSCI 接口将内核引导至 HYP 模式。
通过 u-boot 源代码，我确实看到有一个通用 psci.S 和其他 psci.S 是板特定的并且有以下疑问。
1). psci.S 如何以及在何处适合正常的 u-boot 流程（启动 u-boot 时何时以及如何调用 cpu_on 和 cpu_off 等 psci 服务）。s
2). u-boot的这个psci接口是如何用来在HYP模式下启动内核的（psci接口中有什么可以让Linux内核在HYP模式下启动）？
1). How and where psci.S fits in normal u-boot flow
U-boot 留出一些安全世界内存并在那里复制保护监视器代码，以便它可以在 U-Boot 退出后保持驻留并提供对一些 PSCI SMC 调用的最小处理。
(when and how psci service like cpu_on and cpu_off is called while booting u-boot)
他们不是。 U-Boot 仅在主 CPU 上运行并移交给 Linux。 Linux 可能会在其自己的引导过程中稍后启动辅助内核，但 U-Boot 早已不复存在，除了上述安全监视器代码。
2). How this psci interface of u-boot is used to boot kernel in HYP mode
不是。
(what is it in psci interface that allow Linux kernel to booted in HYP mode)?
没有。
您提到的补丁系列背后的要点是，对于 32 位 ARM 平台来说，具有 TrustZone 感知硬件设计但垃圾软件支持的情况太普遍了（不幸的是现在仍然如此）。供应商 BSP 实现了足够的引导加载程序来启动它，并且从不从引导中切换出安全 SVC 模式，因此整个 Linux 在安全世界中运行，并且它们的内核充满了高度特定于平台的代码直接戳像电源控制器这样的安全硬件。如果您想使用虚拟化，这会带来问题（如果您是 KVM/ARM 的共同维护者并且最近给自己买了一辆 CubieTruck，这显然是一个紧迫的问题......） - 很容易采取此类平台的 U-boot 代码并使其在启动前切换到 NS-HYP Linux，从而启用 KVM（当时上游 U-boot 已经对此提供了一些基本支持），但是一旦你放弃了在安全世界之外，您以后无法使用依赖于仅安全硬件的原始 smp_operations 来启动您的辅助 CPU。
通过实现一些琐碎的运行时 "firmware" 挂在引导加载程序的后面，然后您可以根据需要以最简单的方式回调到安全世界，并且移动必要的平台是最有意义的- 那里的特定代码将操作抽象到一个简单的固件调用接口后面，特别是如果Linux已经有一个合适的支持。
PSCI 本身绝对没有什么特别之处 - 有许多 ARM 平台具有适当的安全固件，它们通过它们自己的专有协议实现电源管理和 SMP 操作。唯一模糊相关的方面是符合 PSCI 规范保证所有 CPU 将以相同模式出现，因此如果您最初在 HYP 中输入 Linux，您将不会看到不匹配的辅助节点出现在其他一些不兼容的模式或安全状态中。