Hi Marc,
On Wed, Jul 31, 2024 at 12:02:24PM +0100, Marc Zyngier wrote:
> On Wed, 31 Jul 2024 11:05:05 +0100,
> Alexandru Elisei <alexandru.elisei@xxxxxxx> 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.
I was referring to what happens when a guest is running at EL1 with virtual
stage 2 enabled and that guest performs an AT instruction. If the stage 1
translation tables are not mapped at virtual stage 2, then KVM should inject a
data abort in the guest hypervisor.
But after thinking about it some more, I guess that's not something that needs
AT trapping: if the stage 1 tables are not mapped in the physical stage 2
(because the level 1 hypervisor unmapped them from the virtual stage 2), then
KVM will get a data abort, and then inject that back into the guest hypervisor.
And as far as I can tell, KVM tracks IPAs becoming unmapped from virtual stage 2
by trapping TLBIs.
So everything looks correct to me, sorry for the noise.
>
> 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).
Yes, that looks correct to me.
>
> >
> > - 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).
That explains it then, thanks for digging out the commit id!
Alex
