qemu-devel
[Top][All Lists]
Advanced

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

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


From: David Hildenbrand
Subject: Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager
Date: Thu, 30 Jan 2025 17:51:08 +0100
User-agent: Mozilla Thunderbird

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]