On Thu, Jun 03, 2021 at 09:39:09AM +0100, Marc Zyngier wrote: > Hi Jamie, > > Funny, your email has a "Mail-Followup-To:" field that contains > everyone but you... Not ideal! ;-) Oops, new mutt config, thanks. > On Thu, 03 Jun 2021 08:07:22 +0100, > Jamie Iles <jamie@xxxxxxxxxxxx> wrote: > > > > 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. > > Ah, the joy of testing with older guests. I guess i should upgrade by > test rig and play with some newer guests at L1. > > > > > 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? > > I'd like to try and avoid that in order to keep the basic logic as > simple as possible for the time being, and as close to the tried and > trusted flow 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. > > I think this is the real thing. We should never propagate trap bits > for features we don't want to support in guests. The L1 kernel sets > these bits unconditionally, despite PtrAuth never being advertised, > which trips the host code. > > Could you try the untested hack below? That fixes the issue that I was seeing, lgtm. Thanks Marc! Jamie _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
