On 22/1/25 02:18, Peter Xu wrote:
On Tue, Jun 25, 2024 at 12:31:13AM +0800, Xu Yilun wrote:
On Mon, Jan 20, 2025 at 03:46:15PM -0500, Peter Xu wrote:
On Mon, Jan 20, 2025 at 09:22:50PM +1100, Alexey Kardashevskiy wrote:
It is still uncertain how to implement the private MMIO. Our assumption
is the private MMIO would also create a memory region with
guest_memfd-like backend. Its mr->ram is true and should be managed by
RamdDiscardManager which can skip doing DMA_MAP in VFIO's region_add
listener.
My current working approach is to leave it as is in QEMU and VFIO.
Agreed. Setting ram=true to even private MMIO sounds hackish, at least
The private MMIO refers to assigned MMIO, not emulated MMIO. IIUC,
normal assigned MMIO is always set ram=true,
void memory_region_init_ram_device_ptr(MemoryRegion *mr,
Object *owner,
const char *name,
uint64_t size,
void *ptr)
{
memory_region_init(mr, owner, name, size);
mr->ram = true;
So I don't think ram=true is a problem here.
I see. If there's always a host pointer then it looks valid. So it means
the device private MMIOs are always mappable since the start?
Yes. VFIO owns the mapping and does not treat shared/private MMIO any
different at the moment. Thanks,
Thanks,
--
Alexey
