[PATCH 2/2] KVM: arm64: Move FGT value configuration to vCPU state

[Mark Brown]

On Fri, Mar 17, 2023 at 04:48:26PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > That's an awful lot of registers with the fine grained traps, and when
> > extended to cover HFHxTR2 there's a bunch of RES0 bits intended for
> > future traps.  It feels a bit unmanagable.  I'd have expected something
> > more along the lines of "enable all traps other than...".  The pattern
> > seemed to be more to have an explicit initialiser for the bits that are
> > set (eg, with CPACR_EL1) which was why I didn't put anything explicit. 

> "an awful lot of registers" is exactly 3 registers as of ARMv8.8/9.3
> that have a disable-trapping-when-set pattern. Maybe more in 9.4 and
> up, but if people can be bothered to write the tools/sysreg file, they
> can also document what gets implicitly trapped.

See my patch on the list for generating the FGT registers, HWFGxTR are
now fully utilised as of the 2022-12 (and we also have HWFGxTR2 now
which is mostly RES0).  The register set for the base register is:

+        * ACCDATA_EL1, GCSPR_EL0, GCSCRE0_EL1, GCSPR_EL1, GCSCR_EL1,
+        * SMPRI_EL1, TPIDR2_EL0, RCWMASK_EL1, PIRE0_EL1, PIR_EL1,
+        * POR_EL0, POR_EL1, S2POR_EL1, MAIR2_EL1, and AMAIR_EL1,

I'd strongly expect the pattern for HWFGxTR2 to be 0 to trap, this is
the case for the few bits already defined there with the rest RES0.

> This also outlines that ACCDATA_EL1 gets trapped while it wasn't
> explicitly trapped before, and that we don't have a handler for it.

Note that it is currently explicitly trapped with no handler given that
we initialise the HWFGxTR registers to 0 by default in the architecture
EL2 entry code and then only ever modify individual bits, there's no
change introduced here.

> So we need an extensive documentation of what the 0 value covers, no
> ifs no buts.

If this is very important it does feel like we might benefit more from
collecting all the information on all the traps in a central place with
pointers out to where things are managed, knowing where to look and
tracing back where values come from is often much more of a hassle than
knowing what the value means.

(I have already added the comment locally as above, this is more a
separate thing.)
-------------- 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/20230317/e405c978/attachment.sig>