On 12/9/20 10:30 AM, Alex Bennée wrote:
>> Nope, nor for most any other out-of-line memory operation performed by any
>> other qemu target. Starting with arm's own dc zva.
>
> Oops - bit of an oversight there. Is this only a problem for linux-user?
> Looking at the dc zva implementation it certainly seems it should be
> going through the memory helpers for softmmu. Maybe all we need to do is
> have a CONFIG_PLUGIN case for user-mode that eschews the memset?
The softmmu version will also go through memset, usually. See
mem = probe_write(env, vaddr, blocklen, mmu_idx, ra);
where we only take the slow path if we can't resolve the virtual address to RAM
(and excluding watchpoints).
> How do we audit all the helpers? Is it just a case of those using memset?
Not always.
For softmmu, I think we need to arrange for some softtlb bit, akin to what we
do for watchpoints, so that all memory accesses are forced through the slow
path.
That means we capture all references, no matter where they're made -- directly
in tcg or via helpers. Which means that we *don't* have to have that separate
secondary call generated in tcg.
Which means we don't have to audit, we've simply changed the machinery under
the covers.
>> There are other changes to the slow path that need changing, because at
>> present
>> I do not have enough bits to represent 256-bit alignment for (specifically)
>> arm32 neon "vld4 {d0-d3},[r0:256]". So perhaps I can work in the plugin
>> thing
>> at the same time.
>
> Expanding MemOp and TCGMemopidx?
No, conflict with softtlb bits.
https://gitlab.com/rth7680/qemu/-/blob/tgt-arm-align/target/arm/translate.c#L882
r~
