Re: [PATCH 14/27] KVM: arm64: Restructure FGT register switching

From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Eric Auger <eric.auger@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will@kernel.org>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Chase Conklin <chase.conklin@arm.com>,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Darren Hart <darren@os.amperecomputing.com>,
	Miguel Luis <miguel.luis@oracle.com>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 14/27] KVM: arm64: Restructure FGT register switching
Date: Wed, 12 Jul 2023 21:06:08 +0100	[thread overview]
Message-ID: <87edlcao9b.wl-maz@kernel.org> (raw)
In-Reply-To: <b9ccca23-65d5-4ed1-976e-63d51e3457e3@sirena.org.uk>

On Wed, 12 Jul 2023 18:15:41 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> On Wed, Jul 12, 2023 at 03:57:57PM +0100, Marc Zyngier wrote:
>
> > As we're about to majorly extend the handling of FGT registers,
> > restructure the code to actually save/restore the registers
> > as required. This is made easy thanks to the previous addition
> > of the EL2 registers, allowing us to use the host context for
> > this purpose.
> 
> > +/*
> > + * FGT register definitions
> > + *
> > + * RES0 and polarity masks as of DDI0487J.a, to be updated as needed.
> > + * We're not using the generated masks as they are usually ahead of
> > + * the published ARM ARM, which we use as a reference.
> > + *
> > + * Once we get to a point where the two describe the same thing, we'll
> > + * merge the definitions. One day.
> > + */
> 
> What's the issue here?  The generated definitions should be aligned with
> what's published in DDI0601.  That AIUI exists in large part due to
> concerns people were having with the amount of time it can take to fold
> new features into the ARM, it's official.

For multiple reasons:

- What's published as DDI0601 is a list of registers, without any
  context and no relation to the wider architecture (it is basically
  the XML dumped as a PDF). That's not enough to implement the
  architecture as it is missing all the content of the engineering
  specs, which are not public documents.

- I have no motivation in supporting the latest and greatest. NV is
  hard enough without all the (still evolving) crop of 8.9/9.4
  extensions.  As long as what I have is a legal implementation and
  runs on the HW I have access to, that's good enough for me.

- I want to look at a single document and support what's in there. Not
  two. Because it is hard enough to follow when you're implementing
  this crap, and even harder for someone trying to review it.

So I firmly intend to totally ignore most of what's outside of the
published ARM ARM unless it makes my life so much easier that I can't
afford not to implement it.

	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