On Wed, Jan 22, 2025 at 03:30:05PM +1100, Alexey Kardashevskiy wrote:
>
>
> 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,
mm.. I'm actually expecting private MMIO not have a host pointer, just
as private memory do.
But I'm not sure why having host pointer correlates mr->ram == true.
Thanks,
Yilun
>
> >
> > Thanks,
> >
>
> --
> Alexey
>
