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

David Hildenbrand
2025-01-30T16:51:14Z

On 30.01.25 17:28, Peter Xu wrote:
> On Sun, Jan 26, 2025 at 11:34:29AM +0800, Xu Yilun wrote:
>>> Definitely not suggesting to install an invalid pointer anywhere. The
>>> mapped pointer will still be valid for gmem for example, but the fault
>>> isn't. We need to differenciate two things (1) virtual address mapping,
>>> then (2) permission and accesses on the folios / pages of the mapping.
>>> Here I think it's okay if the host pointer is correctly mapped.
>>>
>>> For your private MMIO use case, my question is if there's no host pointer
>>> to be mapped anyway, then what's the benefit to make the MR to be ram=on?
>>> Can we simply make it a normal IO memory region? The only benefit of a
>>
>> The guest access to normal IO memory region would be emulated by QEMU,
>> while private assigned MMIO requires guest direct access via Secure EPT.
>>
>> Seems the existing code doesn't support guest direct access if
>> mr->ram == false:
>
> Ah it's about this, ok.
>
> I am not sure what's the best approach, but IMHO it's still better we stick
> with host pointer always available when ram=on. OTOH, VFIO private regions
> may be able to provide a special mark somewhere, just like when romd_mode
> was done previously as below (qemu 235e8982ad39), so that KVM should still
> apply these MRs even if they're not RAM.

I agree.

--
Cheers,

David / dhildenb