[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241113-guestmem-library-v3-0-71fdee85676b@quicinc.com>
Date: Wed, 13 Nov 2024 14:34:35 -0800
From: Elliot Berman <quic_eberman@...cinc.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Andrew Morton
<akpm@...ux-foundation.org>,
Sean Christopherson <seanjc@...gle.com>,
"Fuad
Tabba" <tabba@...gle.com>,
Ackerley Tng <ackerleytng@...gle.com>,
"Mike
Rapoport" <rppt@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
CC: James Gowans <jgowans@...zon.com>, <linux-fsdevel@...r.kernel.org>,
<kvm@...r.kernel.org>, <linux-coco@...ts.linux.dev>,
<linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-mm@...ck.org>, Elliot Berman <quic_eberman@...cinc.com>
Subject: [PATCH RFC v3 0/2] mm: Refactor KVM guest_memfd to introduce
guestmem library
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@...cinc.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,
--
Elliot Berman <quic_eberman@...cinc.com>
Powered by blists - more mailing lists