From: Cornelia Huck <cohuck@redhat.com>
To: eric.auger@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Sebastian Ott <sebott@redhat.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Alireza Sanaee <alireza.sanaee@huawei.com>
Subject: Re: [PATCH v2 2/3] arm: handle CCSIDR_EL1 as a demuxed register
Date: Thu, 02 Apr 2026 17:04:53 +0200 [thread overview]
Message-ID: <87341de73e.fsf@redhat.com> (raw)
In-Reply-To: <93e01647-de7e-4c8e-adb0-7c0bda3f656e@redhat.com>
On Wed, Apr 01 2026, Eric Auger <eric.auger@redhat.com> wrote:
> Hi Connie,
>
> On 2/4/26 2:32 PM, Cornelia Huck wrote:
>> Move handling of CCSIDR_EL1 over to the new *_IDREG_DEMUX
>> infrastructure.
>>
>> Tested-by: Alireza Sanaee <alireza.sanaee@huawei.com>
>> Reviewed-by: Sebastian Ott <sebott@redhat.com>
>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>> ---
>> hw/intc/armv7m_nvic.c | 2 +-
>> target/arm/cpu-sysregs.h | 1 +
>> target/arm/cpu-sysregs.h.inc | 1 +
>> target/arm/cpu.h | 6 ----
>> target/arm/cpu64.c | 12 ++++----
>> target/arm/helper.c | 2 +-
>> target/arm/tcg/cpu32.c | 32 +++++++++----------
>> target/arm/tcg/cpu64.c | 60 ++++++++++++++++++------------------
>> 8 files changed, 56 insertions(+), 60 deletions(-)
>> diff --git a/target/arm/cpu-sysregs.h.inc b/target/arm/cpu-sysregs.h.inc
>> index 3d1ed40f0439..ed466ffb7318 100644
>> --- a/target/arm/cpu-sysregs.h.inc
>> +++ b/target/arm/cpu-sysregs.h.inc
>> @@ -37,6 +37,7 @@ DEF(MVFR2_EL1, 3, 0, 0, 3, 2)
>> DEF(ID_PFR2_EL1, 3, 0, 0, 3, 4)
>> DEF(ID_DFR1_EL1, 3, 0, 0, 3, 5)
>> DEF(ID_MMFR5_EL1, 3, 0, 0, 3, 6)
>> +DEF(CCSIDR_EL1, 3, 1, 0, 0, 0)
> Currently, in [PATCH 0/3] Generate target/arm/cpu-sysregs.h.inc from
> AARCHMRS Registers.json
> and especially [PATCH 1/3] scripts: introduce
> scripts/update-aarch64-sysreg-code.py
> (https://lore.kernel.org/all/20251208163751.611186-4-eric.auger@redhat.com/)
>
>
> CCSIDR_EL1 is not automatically generated.
>
> as target/arm/cpu-sysregs.h.inc should be eventually automatically generated, shouldn't we put this definition somewhere else or do we expect to also automatically generate this demux idreg?
The generation script was explicitly skipping CCSIDR_EL1; when I played
with that script, I just removed it from the list of skipped registers.
I'm not sure if we have information to automatically generate any
demuxed registers, let me see if I can find something.
>
>> DEF(CLIDR_EL1, 3, 1, 0, 0, 1)
>> DEF(ID_AA64ZFR0_EL1, 3, 0, 0, 4, 4)
>> DEF(CTR_EL0, 3, 3, 0, 0, 1)
(...)
>> @@ -792,11 +792,11 @@ static void aarch64_neoverse_v1_initfn(Object *obj)
>> * L3: No L3 (this matches the CLIDR_EL1 value).
>> */
>> /* 64KB L1 dcache */
>> - cpu->ccsidr[0] = make_ccsidr(CCSIDR_FORMAT_CCIDX, 4, 64, 64 * KiB, 0);
>> + SET_IDREG_DEMUX(isar, CCSIDR, 0, make_ccsidr(CCSIDR_FORMAT_CCIDX, 4, 64, 64 * KiB, 0));
>> /* 64KB L1 icache */
>> - cpu->ccsidr[1] = cpu->ccsidr[0];
>> + COPY_IDREG_DEMUX(isar, CCSIDR, 0, 1);
> nit: maybe we don't need a COPY but do get + set, if it is just used in
> this file. Or if we keep copy maybe use the memcpy convention?
Alternatively, we could just set the individual registers to the same
value instead of copying them. I wanted to keep the change obvious here,
but we can also defer adding a copy/memcopy macro until we really need
it.
next prev parent reply other threads:[~2026-04-02 15:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 13:32 [PATCH v2 0/3] arm: demuxed ID registers (CCSIDR_EL1) Cornelia Huck
2026-02-04 13:32 ` [PATCH v2 1/3] arm: handle demuxed ID registers Cornelia Huck
2026-02-04 13:32 ` [PATCH v2 2/3] arm: handle CCSIDR_EL1 as a demuxed register Cornelia Huck
2026-04-01 16:46 ` Eric Auger
2026-04-02 15:04 ` Cornelia Huck [this message]
2026-02-04 13:32 ` [PATCH v2 3/3] arm/kvm: get demuxed ID registers from kvm Cornelia Huck
2026-04-01 17:00 ` Eric Auger
2026-04-02 15:19 ` Cornelia Huck
2026-02-05 11:52 ` [PATCH v2 0/3] arm: demuxed ID registers (CCSIDR_EL1) Peter Maydell
2026-02-05 16:50 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87341de73e.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=alireza.sanaee@huawei.com \
--cc=eric.auger@redhat.com \
--cc=jonathan.cameron@huawei.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sebott@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox