| Message ID | 20241113-guestmem-library-v3-0-71fdee85676b@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: Refactor KVM guest_memfd to introduce guestmem library | expand |
On 13.11.24 23:34, Elliot Berman wrote: > In preparation for adding more features to KVM's guest_memfd, refactor > and introduce a library which abtracts some of the core-mm decisions > about managing folios associated with guest memory. The goal of the > refactor serves two purposes: > > 1. Provide an easier way to reason about memory in guest_memfd. KVM > needs to support multiple confidentiality models (TDX, SEV, pKVM, Arm > CCA). These models support different semantics for when the host > can(not) access guest memory. An abstraction for the allocator and > managing the state of pages will make it eaiser to reason about the > state of folios within the guest_memfd. > > 2. Provide a common implementation for other users such as Gunyah [1] and > guestmemfs [2]. > > In this initial series, I'm seeking comments for the line I'm drawing > between library and user (KVM). I've not introduced new functionality in > this series; the first new feature will probably be Fuad's mappability > patches [3]. Right, or the dummy mmap + vma->set_policy patches for NUMA handling.
In preparation for adding more features to KVM's guest_memfd, refactor and introduce a library which abtracts some of the core-mm decisions about managing folios associated with guest memory. The goal of the refactor serves two purposes: 1. Provide an easier way to reason about memory in guest_memfd. KVM needs to support multiple confidentiality models (TDX, SEV, pKVM, Arm CCA). These models support different semantics for when the host can(not) access guest memory. An abstraction for the allocator and managing the state of pages will make it eaiser to reason about the state of folios within the guest_memfd. 2. Provide a common implementation for other users such as Gunyah [1] and guestmemfs [2]. In this initial series, I'm seeking comments for the line I'm drawing between library and user (KVM). I've not introduced new functionality in this series; the first new feature will probably be Fuad's mappability patches [3]. I've decided to only bring out the address_space from guest_memfd as it seemed the simplest approach. In the current iteration, KVM "attaches" the guestmem to the inode. I expect we'll want to provide some helpers for inode, file, and vm operations when it's relevant to mappability/accessiblity/faultability. I'd appreciate any feedback, especially on how much we should pull into the guestmem library. [1]: https://lore.kernel.org/lkml/20240222-gunyah-v17-0-1e9da6763d38@quicinc.com/ [2]: https://lore.kernel.org/all/20240805093245.889357-1-jgowans@amazon.com/ [3]: https://lore.kernel.org/all/20241010085930.1546800-3-tabba@google.com/ Changes in v3: - Refactor/extract only the address_space - Link to v2: https://lore.kernel.org/all/20240829-guest-memfd-lib-v2-0-b9afc1ff3656@quicinc.com/ Changes in v2: - Significantly reworked to introduce "accessible" and "safe" reference counters - Link to v1: https://lore.kernel.org/r/20240805-guest-memfd-lib-v1-0-e5a29a4ff5d7@quicinc.com Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> --- Elliot Berman (2): KVM: guest_memfd: Convert .free_folio() to .release_folio() mm: guestmem: Convert address_space operations to guestmem library MAINTAINERS | 2 + include/linux/guestmem.h | 33 +++++++ mm/Kconfig | 3 + mm/Makefile | 1 + mm/guestmem.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++ virt/kvm/Kconfig | 1 + virt/kvm/guest_memfd.c | 107 +++++++--------------- 7 files changed, 305 insertions(+), 74 deletions(-) --- base-commit: 5cb1659f412041e4780f2e8ee49b2e03728a2ba6 change-id: 20241112-guestmem-library-68363cb29186 Best regards,