Note: this is on top of <20260105154119.59853-1-cohuck@redhat.com>
("[PATCH v3 0/2] arm: move DCZID_EL0 to idregs array")

While trying to move to an autogenerated cpu-sysregs.h.inc (so that we
may keep a common view on registers), we should first address the ID
registers that are still kept outside of ARMISARegisters. Other than
DCZID_EL0 (addressed by the series this one goes on top of), that's
the CCSIDR_EL1 values kept in cpu->cssidr[] (indexed via CSSELR_EL1.)

My idea was to provide {GET,SET}_IDREG_DEMUX helper that work similar
to {GET,SET}_IDREG and operate on a two-dimensional array. As a side
effect, this also allows to get the values KVM provides for CCSIDR_EL1
(which are virtualized as well.)

RFC because there are still some open questions:
- The demux array cannot easily be autogenerated. We can get rid of the
  ccsidr[] array, but we now have an autogenerated entry in the non-demux
  array that does nothing. Both are not that nice.
- I'm not sure if we need any compat handling for KVM (on TCG, everything
  should stay the same.) In theory, the KVM interface allows setting
  values from userspace (I didn't try.)
- There's a slight disagreement between the current code (providing 16
  entries for CCSIDR_EL1) and the KVM code (providing (7 cache levels) *
  (data/unified, instruction) = 14 entries.) With FEAT_MTE2, we might be
  needing 7 more entries.

Feedback appreciated.

Cornelia Huck (3):
  arm: handle demuxed ID registers
  arm: handle CCSIDR_EL1 as a demuxed register
  arm/kvm: get demuxed ID registers from kvm

 hw/intc/armv7m_nvic.c        |  2 +-
 target/arm/cpu-sysregs.h     |  6 ++++
 target/arm/cpu-sysregs.h.inc |  1 +
 target/arm/cpu.h             | 26 ++++++++++++----
 target/arm/cpu64.c           | 12 ++++----
 target/arm/helper.c          |  2 +-
 target/arm/kvm.c             | 33 ++++++++++++++++++++
 target/arm/tcg/cpu32.c       | 32 +++++++++----------
 target/arm/tcg/cpu64.c       | 60 ++++++++++++++++++------------------
 9 files changed, 114 insertions(+), 60 deletions(-)

-- 
2.52.0

On Mon, 19 Jan 2026, Cornelia Huck wrote:
> Note: this is on top of <20260105154119.59853-1-cohuck@redhat.com>
> ("[PATCH v3 0/2] arm: move DCZID_EL0 to idregs array")
>
> While trying to move to an autogenerated cpu-sysregs.h.inc (so that we
> may keep a common view on registers), we should first address the ID
> registers that are still kept outside of ARMISARegisters. Other than
> DCZID_EL0 (addressed by the series this one goes on top of), that's
> the CCSIDR_EL1 values kept in cpu->cssidr[] (indexed via CSSELR_EL1.)
>
> My idea was to provide {GET,SET}_IDREG_DEMUX helper that work similar
> to {GET,SET}_IDREG and operate on a two-dimensional array. As a side
> effect, this also allows to get the values KVM provides for CCSIDR_EL1
> (which are virtualized as well.)
>
> RFC because there are still some open questions:
> - The demux array cannot easily be autogenerated. We can get rid of the
>  ccsidr[] array, but we now have an autogenerated entry in the non-demux
>  array that does nothing. Both are not that nice.
> - I'm not sure if we need any compat handling for KVM (on TCG, everything
>  should stay the same.) In theory, the KVM interface allows setting
>  values from userspace (I didn't try.)
> - There's a slight disagreement between the current code (providing 16
>  entries for CCSIDR_EL1) and the KVM code (providing (7 cache levels) *
>  (data/unified, instruction) = 14 entries.) With FEAT_MTE2, we might be
>  needing 7 more entries.
>

LGTM!

Reviewed-by: Sebastian Ott <sebott@redhat.com>

Thanks,
Sebastian

On Mon, 19 Jan 2026 18:27:29 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

Hi Cornelia,



> Note: this is on top of <20260105154119.59853-1-cohuck@redhat.com>
> ("[PATCH v3 0/2] arm: move DCZID_EL0 to idregs array")
> 
> While trying to move to an autogenerated cpu-sysregs.h.inc (so that we
> may keep a common view on registers), we should first address the ID
> registers that are still kept outside of ARMISARegisters. Other than
> DCZID_EL0 (addressed by the series this one goes on top of), that's
> the CCSIDR_EL1 values kept in cpu->cssidr[] (indexed via CSSELR_EL1.)
> 
> My idea was to provide {GET,SET}_IDREG_DEMUX helper that work similar
> to {GET,SET}_IDREG and operate on a two-dimensional array. As a side
> effect, this also allows to get the values KVM provides for CCSIDR_EL1
> (which are virtualized as well.)
> 
> RFC because there are still some open questions:
> - The demux array cannot easily be autogenerated. We can get rid of the
>   ccsidr[] array, but we now have an autogenerated entry in the non-demux
>   array that does nothing. Both are not that nice.
> - I'm not sure if we need any compat handling for KVM (on TCG, everything
>   should stay the same.) In theory, the KVM interface allows setting
>   values from userspace (I didn't try.)
> - There's a slight disagreement between the current code (providing 16
>   entries for CCSIDR_EL1) and the KVM code (providing (7 cache levels) *
>   (data/unified, instruction) = 14 entries.) With FEAT_MTE2, we might be
>   needing 7 more entries.
> 
> Feedback appreciated.
> 
> Cornelia Huck (3):
>   arm: handle demuxed ID registers
>   arm: handle CCSIDR_EL1 as a demuxed register
>   arm/kvm: get demuxed ID registers from kvm
> 
>  hw/intc/armv7m_nvic.c        |  2 +-
>  target/arm/cpu-sysregs.h     |  6 ++++
>  target/arm/cpu-sysregs.h.inc |  1 +
>  target/arm/cpu.h             | 26 ++++++++++++----
>  target/arm/cpu64.c           | 12 ++++----
>  target/arm/helper.c          |  2 +-
>  target/arm/kvm.c             | 33 ++++++++++++++++++++
>  target/arm/tcg/cpu32.c       | 32 +++++++++----------
>  target/arm/tcg/cpu64.c       | 60 ++++++++++++++++++------------------
>  9 files changed, 114 insertions(+), 60 deletions(-)
> 

This impacts my set https://lore.kernel.org/all/20260106155828.643-1-alireza.sanaee@huawei.com/

I tested it with mine of course it required a few changes, but looks like working on TCG, didn't try KVM.

Tested-by: Alireza Sanaee <alireza.sanaee@huawei.com>

On Tue, Jan 20 2026, Alireza Sanaee <alireza.sanaee@huawei.com> wrote:

> On Mon, 19 Jan 2026 18:27:29 +0100
> Cornelia Huck <cohuck@redhat.com> wrote:
>
> Hi Cornelia,
>
>
>
>> Note: this is on top of <20260105154119.59853-1-cohuck@redhat.com>
>> ("[PATCH v3 0/2] arm: move DCZID_EL0 to idregs array")
>> 
>> While trying to move to an autogenerated cpu-sysregs.h.inc (so that we
>> may keep a common view on registers), we should first address the ID
>> registers that are still kept outside of ARMISARegisters. Other than
>> DCZID_EL0 (addressed by the series this one goes on top of), that's
>> the CCSIDR_EL1 values kept in cpu->cssidr[] (indexed via CSSELR_EL1.)
>> 
>> My idea was to provide {GET,SET}_IDREG_DEMUX helper that work similar
>> to {GET,SET}_IDREG and operate on a two-dimensional array. As a side
>> effect, this also allows to get the values KVM provides for CCSIDR_EL1
>> (which are virtualized as well.)
>> 
>> RFC because there are still some open questions:
>> - The demux array cannot easily be autogenerated. We can get rid of the
>>   ccsidr[] array, but we now have an autogenerated entry in the non-demux
>>   array that does nothing. Both are not that nice.
>> - I'm not sure if we need any compat handling for KVM (on TCG, everything
>>   should stay the same.) In theory, the KVM interface allows setting
>>   values from userspace (I didn't try.)
>> - There's a slight disagreement between the current code (providing 16
>>   entries for CCSIDR_EL1) and the KVM code (providing (7 cache levels) *
>>   (data/unified, instruction) = 14 entries.) With FEAT_MTE2, we might be
>>   needing 7 more entries.
>> 
>> Feedback appreciated.
>> 
>> Cornelia Huck (3):
>>   arm: handle demuxed ID registers
>>   arm: handle CCSIDR_EL1 as a demuxed register
>>   arm/kvm: get demuxed ID registers from kvm
>> 
>>  hw/intc/armv7m_nvic.c        |  2 +-
>>  target/arm/cpu-sysregs.h     |  6 ++++
>>  target/arm/cpu-sysregs.h.inc |  1 +
>>  target/arm/cpu.h             | 26 ++++++++++++----
>>  target/arm/cpu64.c           | 12 ++++----
>>  target/arm/helper.c          |  2 +-
>>  target/arm/kvm.c             | 33 ++++++++++++++++++++
>>  target/arm/tcg/cpu32.c       | 32 +++++++++----------
>>  target/arm/tcg/cpu64.c       | 60 ++++++++++++++++++------------------
>>  9 files changed, 114 insertions(+), 60 deletions(-)
>> 
>
> This impacts my set https://lore.kernel.org/all/20260106155828.643-1-alireza.sanaee@huawei.com/

Duh, that series had actually been sitting in my "to look at" queue...

>
> I tested it with mine of course it required a few changes, but looks like working on TCG, didn't try KVM.
>
> Tested-by: Alireza Sanaee <alireza.sanaee@huawei.com>

Thanks for testing! I'll also try to take a look at your series.

On Wed, 21 Jan 2026 17:28:07 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Tue, Jan 20 2026, Alireza Sanaee <alireza.sanaee@huawei.com> wrote:
> 
> > On Mon, 19 Jan 2026 18:27:29 +0100
> > Cornelia Huck <cohuck@redhat.com> wrote:
> >
> > Hi Cornelia,
> >
> >
> >  
> >> Note: this is on top of <20260105154119.59853-1-cohuck@redhat.com>
> >> ("[PATCH v3 0/2] arm: move DCZID_EL0 to idregs array")
> >> 
> >> While trying to move to an autogenerated cpu-sysregs.h.inc (so that we
> >> may keep a common view on registers), we should first address the ID
> >> registers that are still kept outside of ARMISARegisters. Other than
> >> DCZID_EL0 (addressed by the series this one goes on top of), that's
> >> the CCSIDR_EL1 values kept in cpu->cssidr[] (indexed via CSSELR_EL1.)
> >> 
> >> My idea was to provide {GET,SET}_IDREG_DEMUX helper that work similar
> >> to {GET,SET}_IDREG and operate on a two-dimensional array. As a side
> >> effect, this also allows to get the values KVM provides for CCSIDR_EL1
> >> (which are virtualized as well.)
> >> 
> >> RFC because there are still some open questions:
> >> - The demux array cannot easily be autogenerated. We can get rid of the
> >>   ccsidr[] array, but we now have an autogenerated entry in the non-demux
> >>   array that does nothing. Both are not that nice.
> >> - I'm not sure if we need any compat handling for KVM (on TCG, everything
> >>   should stay the same.) In theory, the KVM interface allows setting
> >>   values from userspace (I didn't try.)
> >> - There's a slight disagreement between the current code (providing 16
> >>   entries for CCSIDR_EL1) and the KVM code (providing (7 cache levels) *
> >>   (data/unified, instruction) = 14 entries.) With FEAT_MTE2, we might be
> >>   needing 7 more entries.
> >> 
> >> Feedback appreciated.
> >> 
> >> Cornelia Huck (3):
> >>   arm: handle demuxed ID registers
> >>   arm: handle CCSIDR_EL1 as a demuxed register
> >>   arm/kvm: get demuxed ID registers from kvm
> >> 
> >>  hw/intc/armv7m_nvic.c        |  2 +-
> >>  target/arm/cpu-sysregs.h     |  6 ++++
> >>  target/arm/cpu-sysregs.h.inc |  1 +
> >>  target/arm/cpu.h             | 26 ++++++++++++----
> >>  target/arm/cpu64.c           | 12 ++++----
> >>  target/arm/helper.c          |  2 +-
> >>  target/arm/kvm.c             | 33 ++++++++++++++++++++
> >>  target/arm/tcg/cpu32.c       | 32 +++++++++----------
> >>  target/arm/tcg/cpu64.c       | 60 ++++++++++++++++++------------------
> >>  9 files changed, 114 insertions(+), 60 deletions(-)
> >>   
> >
> > This impacts my set https://lore.kernel.org/all/20260106155828.643-1-alireza.sanaee@huawei.com/  
> 
> Duh, that series had actually been sitting in my "to look at" queue...
> 
> >
> > I tested it with mine of course it required a few changes, but looks like working on TCG, didn't try KVM.
> >
> > Tested-by: Alireza Sanaee <alireza.sanaee@huawei.com>  
> 
> Thanks for testing! I'll also try to take a look at your series.
> 
> 

Thanks Cornelia, that patch has been sitting there forever literally :)