On Mon, Jun 30 2025, Peter Maydell <peter.mayd...@linaro.org> wrote: > On Tue, 17 Jun 2025 at 16:41, Cornelia Huck <coh...@redhat.com> wrote: >> >> Generated against Linux 6.15. >> >> Reviewed-by: Sebastian Ott <seb...@redhat.com> >> Reviewed-by: Eric Auger <eric.au...@redhat.com> >> Signed-off-by: Cornelia Huck <coh...@redhat.com> > > Stripping out all the lines that just moved around, > here are the additions: > >> +DEF(ID_AFR0_EL1, 3, 0, 0, 1, 3) > > This is ARMCPU::id_afr0. If we want to store this in > the idregs[] array that's fine but we ought to move it. >
I guess the *afr* regs fell into the cracks because they were not in the isar struct -- makes sense to move them. (This reg "must be interpreted with" MIDR_EL1; I'm wondering if that has any implications once we enlighten guests with possible midr/revidr/aidr values.) >> +DEF(ID_AA64PFR2_EL1, 3, 0, 0, 4, 2) > >> +DEF(ID_AA64FPFR0_EL1, 3, 0, 0, 4, 7) > >> +DEF(ID_AA64DFR2_EL1, 3, 0, 0, 5, 2) > > These are all ID registers we don't implement yet > because we don't implement any features that are > described in them (i.e. our implementation is RAZ/WI). > I guess it's OK to list them here, though we won't > do anything with the array entry. I don't think it hurts to include them, it makes things easier when we want to deal with non-zero values in there via kvm. > >> +DEF(ID_AA64AFR0_EL1, 3, 0, 0, 5, 4) > > ARMCPU::id_aa64afr0 > >> +DEF(ID_AA64AFR1_EL1, 3, 0, 0, 5, 5) > > ARMCPU::id_aa64afr1 > >> +DEF(ID_AA64ISAR3_EL1, 3, 0, 0, 6, 3) > >> +DEF(ID_AA64MMFR4_EL1, 3, 0, 0, 7, 4) > > More ID regs for features we don't implement yet. > >> +DEF(CCSIDR_EL1, 3, 1, 0, 0, 0) > > CCSIDR_EL1 isn't a single ID register, it's an array > of them (indexed by CCSELR_EL1). We keep them in > ARMCPU::ccsidr[]. I don't think it makes sense to > have an entry in isar.idregs[] for this. Hm, IIUC, kvm gets the correct CCSIDR_EL1 under the covers already (i.e. no array). > >> +DEF(CLIDR_EL1, 3, 1, 0, 0, 1) > > ARMCPU::clidr > >> +DEF(CCSIDR2_EL1, 3, 1, 0, 0, 2) > > This is an array too. Currently, kvm handles this as undef. (I think the whole cache stuff might be a bit of a headache.) > >> +DEF(GMID_EL1, 3, 1, 0, 0, 4) > > Another ID register for a feature we don't yet implement > (and a slightly oddball one in that it should UNDEF > until we do implement FEAT_MTE2). > >> +DEF(SMIDR_EL1, 3, 1, 0, 0, 6) > > We implement this as a fixed zero in helper.c. Undef in kvm. > >> +DEF(DCZID_EL0, 3, 3, 0, 0, 7) > > We construct the value of this one in aa64_dczid_read() > based on ARMCPU::dcz_blocksize plus some runtime info. That one's another bit of a headache (I didn't manage to spot kvm code dealing with it.) I'll move the *afr* ones, not yet quite sure how to deal with the cache related ones.
