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

On 7/30/26 8:50 PM, Cédric Le Goater wrote:
> On 7/30/26 12:34, Peter Maydell wrote:
>> On Thu, 30 Jul 2026 at 11:27, Michael S. Tsirkin <[email protected]> wrote:
>>>
>>> On Thu, Jul 30, 2026 at 10:24:32AM +0100, Peter Maydell wrote:
>>>> The idea is rather just to ignore the unaligned-access-to-not-RAM
>>>> case as "only a theoretical issue" and default it to memmove().
>>>> If anybody reports an actual problem we can think about it then :-)
>>
>>> Well given the only reported case of virtio DMA into vfio memory we have is
>>> GH100 and that one is mapped MT_NORMAL, I'm fine with that.
>>
>>> I feel extending vfio to report the mapping type to userspace might
>>> not be a bad idea down the road, though. "Directly accessible"
>>> is a very rough approximation to the rich variety of mappings
>>> available across architectures.
>>
>> Yes, this sounds like a good longer term idea. If userspace doesn't
>> have a way to know what the mapping behind something it's mmap()ed
>> is then it can't know what operations it can and can't safely do.
>>
> Gavin, didn't you have the idea of using a VFIO region caps for that ?
> 
> This is similar to what we did on POWER9 with :
> 
>     VFIO_REGION_INFO_CAP_NVLINK2_SSATGT
> 
> which exported GPU RAM to the userspace too.
> 

The idea was initially proposed by Michael in the comments for (RFCv1)
patch of inheriting the max dma bounce buffer size from the parent [1].

[1] https://lore.kernel.org/qemu-arm/[email protected]/

We can't simply call to glibc::memmove() even it's known that the MemoryRegion
is mapped through MT_NORMAL due to issue that one-byte stores have been translated
to triple one-byte stores by glibc::memmove() in glibc-2.24+ for aarch64 [2].

[2] https://lore.kernel.org/qemu-devel/[email protected]

Besides, I guess we have similar issue on those MemoryRegion created by
memory_region_init_ram_from_{fd, file}. At present, those regions are assumed
to be regular RAM (backed by MT_NORMAL). The assumption isn't always correct.

Thanks,
Gavin