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

[Jamie Iles]

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 at nuviainc.com> 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