Received-SPF: pass (google.com: domain of linux-kernel+bounces-94281-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 6 Mar 2024 16:41:42 +0000
From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	Dave Martin <dave.martin@arm.com>, kvmarm@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 03/14] arm64/fpsimd: Support FEAT_FPMR
Message-ID: <c7e3d57d-92fa-4013-b0fc-e2941fb43d20@sirena.org.uk>
References: <20240122-arm64-2023-dpisa-v4-0-776e094861df@kernel.org>
 <20240122-arm64-2023-dpisa-v4-3-776e094861df@kernel.org>
 <86r0h330dl.wl-maz@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="T+O4zNYAuWrtYgTu"
Content-Disposition: inline
In-Reply-To: <86r0h330dl.wl-maz@kernel.org>


--T+O4zNYAuWrtYgTu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 23, 2024 at 11:07:02AM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > --- a/arch/arm64/kvm/fpsimd.c
> > +++ b/arch/arm64/kvm/fpsimd.c
> > @@ -153,6 +153,7 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
> >  		fp_state.sve_vl =3D vcpu->arch.sve_max_vl;
> >  		fp_state.sme_state =3D NULL;
> >  		fp_state.svcr =3D &vcpu->arch.svcr;
> > +		fp_state.fpmr =3D &vcpu->arch.fpmr;
> >  		fp_state.fp_type =3D &vcpu->arch.fp_type;

> Given the number of fields you keep track of, it would make a lot more
> sense if these FP-related fields were in their own little structure
> and tracked by a single pointer (I don't think there is a case where
> we track them independently).

I sent a patch series that attempted to address this somewhat by
refactoring things so that we initialise the struct we bind during vCPU
setup rather than each time we prepare to switch away from the guest:

    https://lore.kernel.org/linux-arm-kernel/20240226-kvm-arm64-group-fp-da=
ta-v1-0-07d13759517e@kernel.org/

which you weren't terribly enthusiastic about:

    https://lore.kernel.org/all/86y1b027mc.wl-maz@kernel.org/

As covered in the changelog for patch 2 of that series the FP state
includes both system registers which KVM wants to expose via it's system
register ABI and FPSIMD state which the host kernel wants to flag as
suitable for hardended usercopy by embedding in thread_struct.uw.  This
means that pulling everything into a single structure which is used
throughout the kernel would require a bunch of surgery which I'm not
sure is worth the effort or ongoing maintainance cost.=20

The current approach is verbose but not complicated and localised to the
code managing the FP state, as I said in the discussion on that thread I
think it represents a reasonable tradeoff.

--T+O4zNYAuWrtYgTu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXonMYACgkQJNaLcl1U
h9B/+Qf/X/CYJWoG3QUjQ5cmho9TBU5+IqB0WCYPIzgJVWLlUrRY08PS7uM0PF8N
vNaNHLP8Z+zIOThBVW9/pBaXMN9m0jlecqbQAKL0lvtlpFMuzJP4zedWghG9yO+D
rdoghtMVlnOqhPffn3r6+m4XIpXPZ9LCG6qXErTRuqPq+sC43suO71htli7syZH1
TaiV35xQc16sCRmFfGtF9raNEIBNTti+SNYjaglAeQ/XvWIiLIGKKaOLtLyDEUIL
fmCY6Ky815C65RMnc6KwNTnVhv7wfQhpFBRmN2oswlJZbPOocYoNo1vGr1yKi+z7
zHvnBZOnpV5QqRJUCGzLlPE0DIB4hQ==
=MdZw
-----END PGP SIGNATURE-----

--T+O4zNYAuWrtYgTu--