Re: [PATCH RFCv2 02/20] arm/cpu: Add sysreg definitions in cpu-sysregs.h

[Richard Henderson]

On 12/12/24 11:46, Eric Auger wrote:
> > Do we really need anything beyond the defined registers, or even the
> > defined registers for which qemu knows how to do anything?
> what do you mean by "defined registers". The end goal is to be able to
> tune any id reg that the kernel allows to write. So I guess we shall
> encompass more regs than qemu currently handles.

Defined registers as in "have an architected definition".

E.g. there's no need to set any fields in (op0=0 op1=0 crn=0, crm=0, op2=1), because that 
isn't a defined system register.  It's in id register space sure, and almost certainly 
RAZ, but there's no call to either set it or represent it within qemu.

Because you're working to a a symbolic command-line interface, with FEAT_FOO, ID_REG.FIELD 
names, qemu will (be extended to) handle every register named.

> Wrt op1={1,3}, tbh I initially sticked to the KVM API. Now looking at
> D22-2, effectively we have very few ID regs there. If we were to use a
> hashtable we may be more flexible in picking up the indexes that are
> relevant for us.

Yes.  And I'm suggesting the "hashtable" be defined by compile-time constants.

> > const uint32_t id_register_sysreg[NUM_ID_IDX] = {
> >      [ID_AA64ISAR0_IDX] = SYS_ID_AA64PFR0_EL1,
> >      etc
> > };
> >
> > struct ARMISARegisters {
> >      uint64_t id[NUM_ID_IDX];
> > };
> >
> > This seems trivial to automate, and wastes no space.
>
> Sure we will study such rework. As long as the key (ID_AA64ISAR0_IDX)
> can be matched against the index used by the KVM API we should be fine.

I haven't looked to see what KVM_ARM_GET_REG_WRITABLE_MASKS really returns, but I see no 
reason that it should not be trivial to map back and forth between the spaces.


r~