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

From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@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: Thu, 21 Oct 2021 16:57:15 +0100	[thread overview]
Message-ID: <YXGN26tHnRyWkWns@sirena.org.uk> (raw)
In-Reply-To: <20211021151124.3098113-5-maz@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

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.  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.

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!).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]