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>
Subject: Re: [PATCH for-11.0] arm: add DCZID_EL0 to idregs array
Date: Fri, 21 Nov 2025 15:47:20 +0100 [thread overview]
Message-ID: <87y0nzphmv.fsf@redhat.com> (raw)
In-Reply-To: <ef7a800a-99fe-472a-b3a2-c6eff15d65ff@redhat.com>
On Thu, Nov 20 2025, Eric Auger <eric.auger@redhat.com> wrote:
> Hi Connie,
>
> On 11/19/25 2:44 PM, Cornelia Huck wrote:
>> This requires a bit of care, since we still have to handle the EL
>> specific part (DCZID_EL0.DZP). Callers can set/access dcz_blocksize
> what do you mean by EL specific part?
DZP is depending on the current EL (see DC ZVA; it might trap for
EL0/EL1.)
>
> you may simply say that at the moment only bs field is handled as part
> of cpu.dcz_blocklen
> so you replace all the users of that field by accessors to the
> isar.idreg[] storage
Hm, I'm not sure I understand this sentence -- what I wanted to say is
that we care about DCZID_EL0.BS and moving DCZID_EL0 to idregs is made
easier by a simple wrapper for that.
>> via a wrapper working on DCZID_EL.BS.
>>
>> KVM currently does not support DCZID_EL0 via ONE_REG, and actually
>> does not need to work with it, so provide a dummy value for now.
>>
>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(...)
>> @@ -1178,6 +1176,19 @@ struct ARMCPUClass {
>> ResettablePhases parent_phases;
>> };
>>
>> +static inline uint8_t get_dcz_blocksize(ARMCPU *cpu)
> While at it I would replace dcz_blocksize by dczid_el0_bs to be more
> explicit
Can do; I wanted to make the diff more straightforward to use.
>> +{
>> + return cpu->isar.idregs[DCZID_EL0_IDX] & 0xf;
> extract64?
>> +}
>> +
>> +static inline void set_dcz_blocksize(ARMCPU *cpu, uint8_t bs)
>> +{
>> + uint64_t dczid = cpu->isar.idregs[DCZID_EL0_IDX];
>> +
>> + /* keep dzp unchanged */
>> + cpu->isar.idregs[DCZID_EL0_IDX] = (dczid & ~0xf) | bs;
> deposit64?
Can change.
>> +}
>> +
>> /* Callback functions for the generic timer's timers. */
>> void arm_gt_ptimer_cb(void *opaque);
>> void arm_gt_vtimer_cb(void *opaque);
(...)
>> diff --git a/target/arm/helper.c b/target/arm/helper.c
>> index 27ebc6f29b82..8dfeaff25350 100644
>> --- a/target/arm/helper.c
>> +++ b/target/arm/helper.c
>> @@ -3324,7 +3324,8 @@ static uint64_t aa64_dczid_read(CPUARMState *env, const ARMCPRegInfo *ri)
> the name of the function seems to indicate you read the whole DCZID but
> I see the DZP bit is tweaked below. Do you get why we can't return the
> raw id reg?
See above -- the value of DZP depends on the current EL (and some other
bits, which don't change.)
>> if (aa64_zva_access(env, NULL, false) == CP_ACCESS_OK) {
>> dzp_bit = 0;
>> }
>> - return cpu->dcz_blocksize | dzp_bit;
>> +
> nit spurious NL
ok
>> + return cpu->isar.idregs[DCZID_EL0_IDX] | dzp_bit;
>> }
>>
>> static CPAccessResult sp_el0_access(CPUARMState *env, const ARMCPRegInfo *ri,
>> diff --git a/target/arm/kvm.c b/target/arm/kvm.c
>> index 0d57081e69fb..5d65f64addc6 100644
>> --- a/target/arm/kvm.c
>> +++ b/target/arm/kvm.c
>> @@ -2020,6 +2020,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
>> }
>> cpu->mp_affinity = mpidr & ARM64_AFFINITY_MASK;
>>
>> + /*
>> + * We currently do not need this, except for tcg. Should KVM gain support
>> + * for accessing DCZID_EL0 via ONE_REG, we'll overwrite this below. Just
>> + * set a dummy value that corresponds to the minimum value for FEAT_MTE2.
>> + */
>> + set_dcz_blocksize(cpu, 2);
> it is not clear to me why we need that?
We currently don't use it for kvm, but I wanted to put something
non-bogus there. Alternatively, we could moan if we try to access the
reg under kvm.
>> +
>> return kvm_arm_init_cpreg_list(cpu);
>> }
>>
next prev parent reply other threads:[~2025-11-22 2:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 13:44 [PATCH for-11.0] arm: add DCZID_EL0 to idregs array Cornelia Huck
2025-11-20 18:04 ` Eric Auger
2025-11-21 14:47 ` Cornelia Huck [this message]
2025-11-24 17:00 ` Peter Maydell
2025-11-25 16:09 ` Cornelia Huck
2025-11-25 16:49 ` Peter Maydell
2025-11-26 12:59 ` 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=87y0nzphmv.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.