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

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

 



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?

Thanks,

Paolo




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux