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?
Thanks,
--
Peter Xu
