> On Qualcomm SoCs, EL2 is occupied by their HypX hypervisor, so KVM is impossible without exploiting HypX. I don't think OEMs are allowed to do much about it, and it seems to be a somewhat integral part of their platform, so removing it would likely be a big undertaking even if OEMs were allowed to do so.
For Chrome OS firmware stack, full EL2 is given to the kernel, the regular way.
For the Windows on Arm64 stack (on currently shipped SoCs), a mechanism, Secure Launch, is provided to escalate from EL1 to EL2. bootmgfw issues a SMC call, the function is the same as the one used to initialise Intel ACM or AMD SKINIT. QHEE intercepts it, does some sanity and integrity checks then remaps memory to load the TCB launcher and jumps to the entry point. This means that if you run Linux on those, you don't have EL2.
It's a real shame the number of privilege levels is fixed. This seems anti-turing-completeness. Instead, any VM or hypervisor should be able to emulate an environment that is indistinguishable from the environment it itself is running in. That in turn means that hypervisors must be infinitely nestable, and there must be no way for software to know that is running in an emulated environment (unless the hypervisor above wants to reveal this info).
I get that 'infinitely nestable' is hard to implement in hardware, and it's much easier to design things with a fixed nesting depth/number of privilege levels, but I really don't think it would have been much of a stretch to design the instruction set with traps in the right place to allow software to implement infinite nestability without too much of a performance hit.
> but I really don't think it would have been much of a stretch to design the instruction set with traps in the right place to allow software to implement infinite nestability
Nested virtualisation is available for server cores starting from Neoverse V1 onwards, but not for Cortex…
(Also, EL0 could be used as a problem state for this, but some complexities associated to that make it awkward. Unlike POWER (which does have KVM-PR), VBAR doesn’t link to a physical address)
> On Qualcomm SoCs, EL2 is occupied by their HypX hypervisor, so KVM is impossible without exploiting HypX. I don't think OEMs are allowed to do much about it, and it seems to be a somewhat integral part of their platform, so removing it would likely be a big undertaking even if OEMs were allowed to do so.
For Chrome OS firmware stack, full EL2 is given to the kernel, the regular way.
For the Windows on Arm64 stack (on currently shipped SoCs), a mechanism, Secure Launch, is provided to escalate from EL1 to EL2. bootmgfw issues a SMC call, the function is the same as the one used to initialise Intel ACM or AMD SKINIT. QHEE intercepts it, does some sanity and integrity checks then remaps memory to load the TCB launcher and jumps to the entry point. This means that if you run Linux on those, you don't have EL2.