Re: [PATCH v8 13/14] arm/cpu: switch to a generated cpu-sysregs.h.inc

[Cornelia Huck <cohuck@redhat.com>]

On Mon, Jun 30 2025, Peter Maydell <peter.maydell@linaro.org> wrote:

> On Tue, 17 Jun 2025 at 16:41, Cornelia Huck <cohuck@redhat.com> wrote:
>>
>> Generated against Linux 6.15.
>>
>> Reviewed-by: Sebastian Ott <sebott@redhat.com>
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
>> Signed-off-by: Cornelia Huck <cohuck@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.