Re: [PATCH v3 1/2] system/memory: Use qemu_ram_{copy, move}() in ram device region accessors

On 17/7/26 15:55, Michael S. Tsirkin wrote:
> On Fri, Jul 17, 2026 at 02:49:53PM +0100, Peter Maydell wrote:
>> On Fri, 17 Jul 2026 at 14:24, Michael S. Tsirkin <[email protected]> wrote:
>>>
>>> On Thu, Jul 09, 2026 at 07:52:12PM +1000, Gavin Shan wrote:
>>>> Hi Michael and Peter,
>>
>>>>
>>>> Could you help to confirm if the conclusion is to have unified qemu_ram_{copy, move}()
>>>> for all architectures? In qemu_ram_{copy, move}(), the fixed sized accesses like
>>>> 1/2/4/8 bytes are handled by __builtin_{memcpy, memmove}() and fall back to
>>>> memcpy/memmove() for other sized accesses. It's basically what was proposed by
>>>> Michael :-)
>>>
>>> No. __builtin_ and  memcpy/memmove are same on modern linuxes.
>>>
>>> I'd say as a 1st step, on x86 hosts we can do a fixed size
>>> memmove for 1/2/4/8, on other hosts
>>> *aligned* 1/2/4/8 bytes can do
>>>   __atomic_store ... __ATOMIC_RELAXED
>>> and the rest can hobble along on memmove
>>> and hope for the best.
>>
>> I don't think we should be doing something that's x86-host specific,
>> as I've mentioned previously.
>>
>> -- PMM
> 
> Shrug. Of course we already have arch specific code in asm.
> But we can make the unaligned 1/2/4/8 for x86 host a separate
> optimization on top. They are unlikely to be common.

Note we have include/qemu/host-pci-mmio.h with s390x specific
optimizations in util/s390x_pci_mmio.c ...