Thread (51 messages) 51 messages, 10 authors, 2021-12-03

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

From: Chao Peng <hidden>
Date: 2021-11-23 14:34:50
Also in: kvm, linux-fsdevel, lkml, qemu-devel

On Tue, Nov 23, 2021 at 10:06:02AM +0100, Paolo Bonzini wrote:
On 11/19/21 16:39, David Hildenbrand wrote:
quoted
quoted
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.
I'm satisified with this naming ;)
Chao, can you also put this under a new CONFIG such as "bool MEMFD_OPS", and
select it from KVM?
Yes, reasonable.
Thanks,

Paolo
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help