[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6ea4127b-813d-49b0-9922-b5f298ca5f0e@sirena.org.uk>
Date: Wed, 20 Aug 2025 23:13:52 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>,
Joey Gouly <joey.gouly@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Shuah Khan <shuah@...nel.org>, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, kvmarm@...ts.linux.dev,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v15 2/6] KVM: arm64: Manage GCS access and registers for
guests
On Wed, Aug 20, 2025 at 10:06:49PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:
> > In order to allow userspace to control availability of the feature to
> > guests we enable writability for only ID_AA64PFR1_EL1.GCS, this is a
> > deliberately conservative choice to avoid errors due to oversights.
> > Further fields should be made writable in future.
> I'm not sure what you mean by that. Making the feature field writable
> is only allowable if we have some level of support (and otherwise we
> should prevent both the feature being exposed, and the field being
> writable).
> So future fields being writable will only happen when the features are
> fully supported, and only then.
> Please clarify, or drop this altogether.
That's bitrot from earlier versions where we needed to enable
ID_AA64PFR1_EL1, the other versions were similar. I'll remove these
stale references.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists