[Top][All Lists]

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

Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST

From: Paolo Bonzini
Subject: Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST
Date: Tue, 23 Nov 2021 10:06:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

On 11/19/21 16:39, David Hildenbrand wrote:
If qmeu can put all the guest memory in a memfd and not map it, then
I'd also like to see that the IOMMU can use this interface too so we
can have VFIO working in this configuration.

In QEMU we usually want to (and must) be able to access guest memory
from user space, with the current design we wouldn't even be able to
temporarily mmap it -- which makes sense for encrypted memory only. The
corner case really is encrypted memory. So I don't think we'll see a
broad use of this feature outside of encrypted VMs in QEMU. I might be
wrong, most probably I am:)

It's not _that_ crazy an idea, but it's going to be some work to teach KVM that it has to kmap/kunmap around all memory accesses.

I think it's great that memfd hooks are usable by more than one subsystem, OTOH it's fair that whoever needs it does the work---and VFIO does not need it for confidential VMs, yet, so it should be fine for now to have a single user.

On the other hand, as I commented already, the lack of locking in the register/unregister functions has to be fixed even with a single user. Another thing we can do already is change the guest_ops/guest_mem_ops to something like memfd_falloc_notifier_ops/memfd_pfn_ops, and the register/unregister functions to memfd_register/unregister_falloc_notifier.

Chao, can you also put this under a new CONFIG such as "bool MEMFD_OPS", and select it from KVM?



reply via email to

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