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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
