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

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 [off-list ref] wrote:

quoted

Hi Marc,

On Mon, May 10, 2021 at 05:58:14PM +0100, Marc Zyngier wrote:

quoted

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.

quoted

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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel