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

[Mark Brown]

On Wed, Jul 12, 2023 at 09:06:08PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

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

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

Right, it's not the full spec - I was just thinking it was enough to
cover the use here with finding RES0 bits.  The actual XML is
downloadable as well, via 

    https://developer.arm.com/downloads/-/exploration-tools

if that's more convenient (I am not sure why that's not available if you
go looking for DDI0601), not that that addresses the issue with not
having the non-XML part of things.  I know the people responsible for
producing the ARM are actively working on improving the production
process to address the lag so the ARM is available much more promptly.

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

That's definitely fair, my concern here is the risk that we might end up
with issues due to the manual definitions drifting from the generated
ones without people noticing as things go forwards.  Hopefully that's a
minor risk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230712/ed58155e/attachment.sig>