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

From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory
Date: Wed, 27 Jul 2022 10:52:34 +0100	[thread overview]
Message-ID: <874jz2yja5.wl-maz@kernel.org> (raw)
In-Reply-To: <875yjiyka4.wl-maz@kernel.org>

On Wed, 27 Jul 2022 10:30:59 +0100,
Marc Zyngier <maz@kernel.org> wrote:
> 
> On Tue, 26 Jul 2022 18:51:21 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > Doesn't pinning the buffer also imply pinning the stage 1 tables
> > responsible for its translation as well? I agree that pinning the buffer
> > is likely the best way forward as pinning the whole of guest memory is
> > entirely impractical.

Huh, I just realised that you were talking about S1. I don't think we
need to do this. As long as the translation falls into a mapped
region (pinned or not), we don't need to worry.

If we get a S2 translation fault from SPE, we just go and map it. And
TBH the pinning here is just a optimisation against things like swap,
KSM and similar things. The only thing we need to make sure is that
the fault is handled in the context of the vcpu that owns this SPU.

Alex, can you think of anything that would cause a problem (other than
performance and possible blackout windows) if we didn't do any pinning
at all and just handled the SPE interrupts as normal page faults?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm