[PATCH 00/12] KVM: arm64: nv: Add support for address translation instructions

[Marc Zyngier]

On Wed, 31 Jul 2024 11:05:05 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Hi Marc,
> 
> On Tue, Jun 25, 2024 at 02:34:59PM +0100, Marc Zyngier wrote:
> > Another task that a hypervisor supporting NV on arm64 has to deal with
> > is to emulate the AT instruction, because we multiplex all the S1
> > translations on a single set of registers, and the guest S2 is never
> > truly resident on the CPU.
> 
> I'm unfamiliar with the state of NV support in KVM, but I thought I would have a
> look at when AT trapping is enabled. As far as I can tell, it's only enabled in
> vhe/switch.c::__activate_traps() -> compute_hcr() if is_hyp_ctct(vcpu). Found
> this by grep'ing for HCR_AT.
> 
> Assuming the above is correct, I am curious about the following:
> 
> - The above paragraph mentions guest's stage 2 (and the code takes that into
>   consideration), yet when is_hyp_ctxt() is true it is likely that the guest
>   stage 2 is not enabled. Are you planning to enable the AT trap based on
>   virtual HCR_EL2.VM being set in a later series?

I don't understand what you are referring to. AT traps and the guest's
HCR_EL2.VM are totally orthogonal, and are (or at least should be)
treated independently.

But more importantly, there are a bunch of cases where you have no
other choice but trap, and that what I allude to when I say "because
we multiplex all the S1 translations on a single set of register".

If I'm running the EL2 part of the guest, and that guest executes an
AT S1E1R while HCR_EL2.{E2H,TGE}={1,0}, it refers to the guest's EL1&0
translation regime. I can't let the guest execute it, because it would
walk its view of the EL2&0 regime. So we need to trap, evaluate what
the guest is trying to do, and do the walk in the correct context (by
using the instructions or the SW walk).

> 
> - A guest might also set the HCR_EL2.AT bit in the virtual HCR_EL2 register. I
>   suppose I have the same question, injecting the exception back into the guest
>   is going to be handled in another series?

This is already handled. The guest's HCR_EL2 is always folded into the
runtime configuration, and the resulting trap handled through the
existing trap routing infrastructure (see d0fc0a2519a6d, which added
the triaging of most traps resulting from HCR_EL2).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.