Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,
Yilun

> currently QEMU heavily rely on that flag for any possible direct accesses.
> E.g., in memory_access_is_direct().
> 
> -- 
> Peter Xu
> 
> 




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux