Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory

[Oliver Upton <oliver.upton@linux.dev>]

Hey Alex,

On Mon, Sep 12, 2022 at 03:50:46PM +0100, Alexandru Elisei wrote:

[...]

> > Yeah, that would be good to follow up on what other OSes are doing.
> 
> FreeBSD doesn't have a SPE driver.
> 
> Currently in the process of finding out how/if Windows implements the
> driver.
> 
> > You'll still have a nondestructive S2 fault handler for the SPE, right?
> > IOW, if PMBSR_EL1.DL=0 KVM will just unpin the old buffer and repin the
> > new one.
> 
> This is how I think about it: a S2 DABT where DL == 0 can happen because of
> something that the VMM, KVM or the guest has done:
> 
> 1. If it's because of something that the host's userspace did (memslot was
> changed while the VM was running, memory was munmap'ed, etc). In this case,
> there's no way for KVM to handle the SPE fault, so I would say that the
> sensible approach would be to inject an SPE external abort.
> 
> 2. If it's because of something that KVM did, that can only be because of a
> bug in SPE emulation. In this case, it can happen again, which means
> arbitrary blackout windows which can skew the profiling results. I would
> much rather inject an SPE external abort then let the guest rely on
> potentially bad profiling information.
> 
> 3. The guest changes the mapping for the buffer when it shouldn't have: A.
> when the architecture does allow it, but KVM doesn't support, or B. when
> the architecture doesn't allow it. For both cases, I would much rather
> inject an SPE external abort for the reasons above. Furthermore, for B, I
> think it would be better to let the guest know as soon as possible that
> it's not following the architecture.
> 
> In conclusion, I would prefer to treat all SPE S2 faults as errors.

My main concern with treating S2 faults as a synthetic external abort is
how this behavior progresses in later versions of the architecture.
SPEv1p3 disallows implementations from reporting external aborts via the
SPU, instead allowing only for an SError to be delivered to the core.

I caught up with Will on this for a little bit:

Instead of an external abort, how about reporting an IMP DEF buffer
management event to the guest? At least for the Linux driver it should
have the same effect of killing the session but the VM will stay
running. This way there's no architectural requirement to promote to an
SError.

--
Thanks,
Oliver

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