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~
