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

Alexey Kardashevskiy
2025-01-22T04:30:15Z

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