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

Cédric Le Goater <[email protected]> Thu, 30 Jul 2026 12:50:03 +0200
Newsgroups org.nongnu.qemu-arm,org.nongnu.qemu-devel
Message-ID <[email protected]>
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.

Thanks,

C.