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.