[PATCH v4 00/66] KVM: arm64: ARMv8.3/8.4 Nested Virtualization support

[Jamie Iles]

Hi Marc,

On Mon, May 10, 2021 at 05:58:14PM +0100, Marc Zyngier wrote:
> Here the bi-annual drop of the KVM/arm64 NV support code.
> 
> Not a lot has changed since [1], except for a discovery mechanism for
> the EL2 support, some tidying up in the idreg emulation, dropping RMR
> support, and a rebase on top of 5.13-rc1.
> 
> As usual, blame me for any bug, and nobody else.
> 
> It is still massively painful to run on the FVP, but if you have a
> Neoverse V1 or N2 system that is collecting dust, I have the right
> stuff to keep it busy!

I've been testing this series on FVP and get a crash when returning from 
__kvm_vcpu_run_vhe because the autiasp is failing.

The problem is when the L1 boots and during EL2 setup sets hcr_el2 to 
HCR_HOST_NVHE_FLAGS and so enables HCR_APK|HCR_API.  Then the guest 
enter+exit logic in L0 starts performing the key save restore, but as we 
didn't go through __hyp_handle_ptrauth, we haven't saved the host keys 
and invoked vcpu_ptrauth_enable() so restore the host keys back to 0.

I wonder if the pointer auth keys should be saved+restored 
unconditionally for a guest when running nested rather than the lazy 
faulting that we have today?  Alternatively we would need to duplicate 
the lazy logic for hcr_el2 writes.  A quick hack of saving the host keys 
in __kvm_vcpu_run_vhe before sysreg_save_host_state_vhe is enough to 
allow me to boot an L1 with --nested and then an L2.

Do we also need to filter out HCR_APK|HCR_API for hcr_el2 writes when 
pointer authentication hasn't been exposed to the guest?  I haven't yet 
tried making ptrauth visible to the L1.

Thanks,

Jamie