Re: [PATCH 5/5] KVM: arm64: Exclude FP ownership from kvm_vcpu_arch

From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>,
	James Clark <james.clark@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>
Subject: Re: [PATCH 5/5] KVM: arm64: Exclude FP ownership from kvm_vcpu_arch
Date: Mon, 4 Mar 2024 19:10:08 +0000	[thread overview]
Message-ID: <6acffbef-6872-4a15-b24a-7a0ec6bbb373@sirena.org.uk> (raw)
In-Reply-To: <20240302111935.129994-6-maz@kernel.org>

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

On Sat, Mar 02, 2024 at 11:19:35AM +0000, Marc Zyngier wrote:
> In retrospect, it is fairly obvious that the FP state ownership
> is only meaningful for a given CPU, and that locating this
> information in the vcpu was just a mistake.
> 
> Move the ownership tracking into the host data structure, and
> rename it from fp_state to fp_owner, which is a better description
> (name suggested by Mark Brown).

The SME patch series proposes adding an additional state to this
enumeration which would say if the registers are stored in a format
suitable for exchange with userspace, that would make this state part of
the vCPU state.  With the addition of SME we can have two vector lengths
in play so the series proposes picking the larger to be the format for
userspace registers.  

We could store this separately to fp_state/owner but it'd still be a
value stored in the vCPU.  Storing in a format suitable for userspace
usage all the time when we've got SME would most likely result in
performance overhead if nothing else and feels more complicated than
rewriting the data in the relatively unusual case where userspace looks
at it.  Trying to convert userspace writes into the current layout would
have issues if the current layout uses the smaller vector length and
create fragility with ordering issues when loading the guest state.

The proposal is not the most lovely idea ever but given the architecture
I think some degree of clunkiness would be unavoidable.  

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