Re: [PATCH] KVM: arm64: Only save S1PIE registers when dirty

From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Only save S1PIE registers when dirty
Date: Mon, 04 Mar 2024 14:39:19 +0000	[thread overview]
Message-ID: <86v86212p4.wl-maz@kernel.org> (raw)
In-Reply-To: <50c5cdd2-fceb-44c4-aff1-dc98180161a1@sirena.org.uk>

On Mon, 04 Mar 2024 14:11:19 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> On Sat, Mar 02, 2024 at 10:28:18AM +0000, Marc Zyngier wrote:
> > Mark Brown <broonie@kernel.org> wrote:
> > > On Fri, Mar 01, 2024 at 07:32:28PM +0000, Oliver Upton wrote:
> 
> > > > The overheads of guest exits are extremely configuration dependent, and
> > > > on VHE the save/restore of EL1 state happens at vcpu_load() / vcpu_put()
> > > > rather than every exit. There isn't a whole lot KVM can do to lessen the
> > > > blow of sharing EL1 in the nVHE configuration.
> 
> > > > Looking a bit further out, the cost of traps will be dramatically higher
> > > > when running as a guest hypervisor, so we'd want to avoid them if
> > > > possible...
> 
> > > Indeed, but OTOH I got some complaints about adding more system register
> 
> > Complains from whom? I can't see anything in my inbox, so it my
> > conclusion that these "issues" are not serious enough to be publicly
> > mentioned.
> 
> This was you saying that adding more registers to be context switched
> here needed special explanation, rather than just being the default and
> generally unremarkable place to put context switching of registers for
> EL0/1.

What I remember saying is that it is wrong to add extra registers to
the context switch without gating them with the VM configuration.
Which is a very different thing.

I don't know where you got the idea that I wanted to make this sort of
things lazy. Quite the contrary, actually. I want to trap things to
make them UNDEF. And this is exactly how -next now behaves (see
58627b722ee2).

What I want to see explained in all cases is why a register has to be
eagerly switched and not deferred to the load/put phases, specially on
VHE. because that has a very visible impact on the overall performance.

> > If anything, I'm actually minded to remove existing instances of this
> > stupid trapping, such as PAuth, which is entirely pointless.
> 
> That one was part of why it appeared that this sort of thing was what
> you were asking for.

No, really not.

	M.

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