Re: [PATCH 4/4] arm64/fpsimd: Document the use of TIF_FOREIGN_FPSTATE by KVM

From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Quentin Perret <qperret@google.com>,
	Will Deacon <will@kernel.org>,
	kernel-team@android.com
Subject: Re: [PATCH 4/4] arm64/fpsimd: Document the use of TIF_FOREIGN_FPSTATE by KVM
Date: Wed, 27 Oct 2021 12:26:33 +0100	[thread overview]
Message-ID: <8735ombtee.wl-maz@kernel.org> (raw)
In-Reply-To: <YXGN26tHnRyWkWns@sirena.org.uk>

On Thu, 21 Oct 2021 16:57:15 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Thu, Oct 21, 2021 at 04:11:24PM +0100, Marc Zyngier wrote:
> > The bit of documentation that talks about TIF_FOREIGN_FPSTATE
> > does not mention the ungodly tricks that KVM plays with this flag.
> > 
> > Try and document this for the posterity.
> 
> Yes, more documentation here would definitely be helpful - it's pretty
> hard to follow what KVM is doing here.
> 
> >   * CPU currently contain the most recent userland FPSIMD state of the current
> > - * task.
> > + * task *or* the state of the corresponding KVM vcpu if userspace is behaving
> > + * as a VMM and that the vcpu has used FP during its last run. In the latter
> > + * case, KVM will set TIF_FOREIGN_FPSTATE on kvm_vcpu_put(). For all intents
> > + * and purposes, the vcpu FP state is treated identically to userspace's.
> 
> I'm not able to find a kvm_vcpu_put() function in upstream, just
> kvm_cpu_put_sysregs_vhe().  There's kvm_arch_vcpu_put() which is called
> from the vcpu_put() function in generic KVM code but they don't show up
> until you start mangling the name in that comment.

You, vcpu_put() is the one I had in mind.

> It'd be good to
> mention what vcpu_put() is actually doing and a bit more about the
> general model, KVM is behaving differently here AFAICT in that it flags
> the current state as invalid when it saves the context to memory rather
> than when an event happens that requires that the context be reloaded.
> There's no problem there but it's a bit surprising due the difference
> and worth highlighting.

There is a bit more to it: KVM flags the userspace state as invalid,
but also ties the guest state to the current task via
fpsimd_bind_state_to_cpu() so that the state can be saved on
vcpu_put() via fpsimd_save_and_flush_cpu_state(), or if we end-up
running kernel_neon_begin() because of some softirq handling.

> I think I'd also be inclined to restructure this to foreground the fact
> that it's the state of the current task but that task may be a VMM.  So
> something more like
> 
> 	...contain the most recent FPSIMD state of the current userspace
> 	task.  If the task is behaving as a VMM then this will be
> 	managed by KVM which will...
> 
> making it a bit easier to follow (assuming my understanding of what's
> going on is correct, if not then I guess something else needs
> clarifying!).

I'll have a go at rewriting this.

	M.

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

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