Re: [PATCH v4 2/3] system/memory: Use qemu_ram_move() for directly accessible regions

On 7/28/26 12:02 AM, Peter Xu wrote:
> On Mon, Jul 27, 2026 at 01:51:45PM +0100, Peter Maydell wrote:
>> I think we could usefully expand this comment, because the reasons
>> we need it are not immediately obvious. How about:
>>
>> ===begin===
>> Move @n bytes from @src to @dst; the memory areas may overlap.
>> This provides the same semantics as memmove(), plus an additional
>> stronger guarantee: if @n is 1, 2 or 4 or 8 bytes, and @src
>> and @dst are both naturally aligned for that access size, and
>> the memory areas do not overlap, then both the load and the store
>> will be done as a single atomic access (with the semantics of
>> qatomic_read() and qatomic_set()).
>>
>> This is the underlying function that we use to implement accesses
>> by a guest vCPU or a device DMA operation to a ram block. The
>> atomic guarantee is needed for two major cases:
>>   - when the ram block is backed by a PCI BAR passed through
>>     from a host device (and so it might be hardware registers
>>     that must be accessed exactly once at the right width)
>>   - when an emulated device updates a data structure shared in
>>     guest memory with guest software (e.g. a network device's
>>     set of tx and rx descriptor blocks), if a write to memory
>>     is accidentally performed multiple times then it can break
>>     the guest code.
> 
> Maybe also append it with "the guest code when it busy polls the guest
> memory"; I just found that the polling model isn't something obvious too
> when reading it first.
> 

The extended context has been included for (v5).

>>
>> We don't attempt to perform the exact access when it would
>> be unaligned, because this can't necessarily be done on
>> all host architectures; although this is strictly speaking
>> not doing what would happen on real hardware, we don't think
>> there are going to be situations where that matters in practice.
> 
> Oh yes, mentioning the unaligned part of discussion would also be nice, I
> forgot it when replying.
> 

+1. The context has been included for (v5) either.

Thanks,
Gavin