On Tue, 01 Jun 2021 10:53:49 +0100, Dongjiu Geng gengdongjiu1@gmail.com wrote:
Mark Rutland mark.rutland@arm.com 于2021年6月1日周二 下午5:19写道：
On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote:
Hi All, when Linux kernel boot from EL1, there is no method to let kernel to enter EL2 to enable hypervisor. so I want to add an SMC interface between kernel and EL3 ATF to let kernel can set the hypervisor vector table, then can enter EL2 to enable hypervisor, as shown in [1]. Do you agree? Otherwise there is no method to enter EL2 hypervisor when kernel boot from EL1, because the hypervisor vector table(vbar_el2) is unknown.
The kernel already supported being booted at EL2, where it will install itself as the hypervisor (and will drop to EL1 if required). EL2 is the preferred boot mode, as we document in:
https://www.kernel.org/doc/html/latest/arm64/booting.html
... where we say:
| The CPU must be in either EL2 (RECOMMENDED in order to have access to | the virtualisation extensions) or non-secure EL1.
We *strongly* prefer this over adding new ABIs to transition from EL1 to EL2. Please boot the kernel at EL2 if you want to use KVM.
Thanks for the answer. If use KVM, it should boot from EL2. But if the hypervisor is not KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the host kernel from EL1(not follow above rule), it seems there is not way to enter the Jailhouse hypervisor.
We only deal with two cases: - either the kernel uses its own, built-in hypervisor: it boots at EL2, and installs itself.
- or there is a pre-existing hypervisor, and the kernel boots at EL1.
In the past, Jailhouse used the exact same entry points as KVM. What has changed?
Finally, if you can change the firmware to install the EL2 vectors, you can also change it to enter the kernel at EL2. I suggest you do that instead.
Thanks,
M.