Re: [PATCH 04/17] target/arm: Raise alignment fault for DC_ZVA on Device memory

On 7/28/26 07:21, Peter Maydell wrote:
> On Sat, 18 Jul 2026 at 00:26, Richard Henderson
> <[email protected]> wrote:
>>
>> Raise alignment fault when DC_ZVA targets Device memory, as required
>> by the architecture.  With MTE, an alignment exception is not always
>> correctly ordered vs a tag check fail exception -- to be fixed in
>> followup patches.
>>
>> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3005
>> Signed-off-by: Richard Henderson <[email protected]>
> 
>>
>> +void HELPER(dc_zva)(CPUARMState *env, uint64_t addr)
>> +{
>> +    uintptr_t ra = GETPC();
>> +    size_t len = (size_t)4 << get_dczid_bs(env_archcpu(env));
>> +    int mmu_idx = arm_env_mmu_index(env);
>> +    MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> 
> I feel like some static analyzer or compiler is going to complain
> that this assignment is pointless in the !CONFIG_USER_ONLY case.
> Maybe better to set attrs = MEMTXATTRS_UNSPECIFIED inside the
> #ifdef CONFIG_USER_ONLY block ?

It's officially used as an argument to do_dcxva_traps, so we're safe there.  It's ignored 
within that function, but we don't enable -Wunused-parameter, and even if we did I'd then 
annotate with G_GNUC_UNUSED.

> Is 0 really the right size to pass in here? Looking at
> probe_access_full(), if you pass in a 0 size then it will
> call notdirty_write() with a dirtysize parameter of 1,
> which will then not invalidate or set the VGA/migration
> dirty bits on the full range of memory we're about to clear.
> This would be OK if we then went through the slowpath and
> did a set of byte accesses, but probe_access_full() will
> clear TLB_NOTDIRTY from the flags it returns to us if it
> called notdirty_write(), so we will take the fastpath if
> that was the only flag set.
> 
> Maybe probe_access_full(), probe_access_full_mmu() and
> probe_access_flags() should not call notdirty_write() and
> clear TLB_NOTDIRTY from the flags they return if the passed
> in size is 0 ?
> 
> The notdirty_write() API also wants the base address of the
> DC ZVA block (since that's where we will be writing from),
> not the address from the guest.
> 
> (We may be getting away with some of this because of various
> functions rounding up/down to full page addresses, but none
> of these functions seem to document that, so we shouldn't
> rely on it.)

Good questions.  AFAIK, passing 0 to probe kinda-sorta means "the page".  But I'll 
double-check what's going on.  Needing to explicitly handle dirty is I think rare enough 
that we can leave that to a couple of callers.  SVE might get need a poke with any changes.


r~