| Message ID | 20201116204318.63987-1-dbrazdil@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Opt-in always-on nVHE hypervisor | expand |
On Mon, 16 Nov 2020 20:42:54 +0000, David Brazdil <dbrazdil@google.com> wrote: > > As we progress towards being able to keep guest state private to the > host running nVHE hypervisor, this series allows the hypervisor to > install itself on newly booted CPUs before the host is allowed to run > on them. > > All functionality described below is opt-in, guarded by an early param > 'kvm-arm.protected'. Future patches specific to the new "protected" mode > should be hidden behind the same param. > > The hypervisor starts trapping host SMCs and intercepting host's PSCI > CPU_ON/SUSPEND calls. It replaces the host's entry point with its own, > initializes the EL2 state of the new CPU and installs the nVHE hyp vector > before ERETing to the host's entry point. > > The kernel checks new cores' features against the finalized system > capabilities. To avoid the need to move this code/data to EL2, the > implementation only allows to boot cores that were online at the time of > KVM initialization and therefore had been checked already. > > Other PSCI SMCs are forwarded to EL3, though only the known set of SMCs > implemented in the kernel is allowed. Non-PSCI SMCs are also forwarded > to EL3. Future changes will need to ensure the safety of all SMCs wrt. > private guests. > > The host is still allowed to reset EL2 back to the stub vector, eg. for > hibernation or kexec, but will not disable nVHE when there are no VMs. > > Tested on Rock Pi 4b, based on 5.10-rc4. Adding Lorenzo and Sudeep for the PSCI side of things. Thanks, M.
Hi David, On Mon, 16 Nov 2020 20:42:54 +0000, David Brazdil <dbrazdil@google.com> wrote: > > As we progress towards being able to keep guest state private to the > host running nVHE hypervisor, this series allows the hypervisor to > install itself on newly booted CPUs before the host is allowed to run > on them. > > All functionality described below is opt-in, guarded by an early param > 'kvm-arm.protected'. Future patches specific to the new "protected" mode > should be hidden behind the same param. > > The hypervisor starts trapping host SMCs and intercepting host's PSCI > CPU_ON/SUSPEND calls. It replaces the host's entry point with its own, > initializes the EL2 state of the new CPU and installs the nVHE hyp vector > before ERETing to the host's entry point. > > The kernel checks new cores' features against the finalized system > capabilities. To avoid the need to move this code/data to EL2, the > implementation only allows to boot cores that were online at the time of > KVM initialization and therefore had been checked already. > > Other PSCI SMCs are forwarded to EL3, though only the known set of SMCs > implemented in the kernel is allowed. Non-PSCI SMCs are also forwarded > to EL3. Future changes will need to ensure the safety of all SMCs wrt. > private guests. > > The host is still allowed to reset EL2 back to the stub vector, eg. for > hibernation or kexec, but will not disable nVHE when there are no VMs. I have now been through the whole series, and I don't think there is anything really major (although I haven't tried it yet). I think it would benefit from being rebased on top of kvmarm/queue, as it'd give you the opportunity to replace a number of per-CPU state fields with global function pointers. Another thing is that we seem to have diverging interpretations of the PSCI spec when it comes to CPU_SUSPEND. Finally, please include the PSCI maintainers in your next posting, as I'll need their Ack to pick the first few patches. Thanks, M.