Paolo,

The arm64 patches have been Reviewed-by Marc, and AFAICT the x86 side of
things is a go.  Barring a screwup on my end, this just needs your approval.

Assuming everything looks good, it'd be helpful to get this into kvm/next
shortly after rc1.  The x86 Kconfig changes in particular create semantic
conflicts with in-flight series.


Add support for host userspace mapping of guest_memfd-backed memory for VM
types that do NOT use support KVM_MEMORY_ATTRIBUTE_PRIVATE (which isn't
precisely the same thing as CoCo VMs, since x86's SEV-MEM and SEV-ES have
no way to detect private vs. shared).

mmap() support paves the way for several evolving KVM use cases:

 * Allows VMMs like Firecracker to run guests entirely backed by
   guest_memfd [1]. This provides a unified memory management model for
   both confidential and non-confidential guests, simplifying VMM design.

 * Enhanced Security via direct map removal: When combined with Patrick's
   series for direct map removal [2], this provides additional hardening
   against Spectre-like transient execution attacks by eliminating the
   need for host kernel direct maps of guest memory.

 * Lays the groundwork for *restricted* mmap() support for guest_memfd-backed
   memory on CoCo platforms [3] that permit in-place
   sharing of guest memory with the host.

Based on kvm/queue.

[1] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding
[2] https://lore.kernel.org/all/20250221160728.1584559-1-roypat@amazon.co.uk
[3] https://lore.kernel.org/all/20250328153133.3504118-1-tabba@google.com

v17:
 - Collect reviews. [Xiaoyao, David H.]
 - Write a better changelog for the CONFIG_KVM_GENERIC_PRIVATE_MEM =>
   CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE rename. [Xiaoyao]
 - Correctly gmem_max_mapping_level()'s '0' return in the right patch. [Xiaoyao]
 - Replace call to kvm_gmem_get_pfn() with a WARN_ONCE() in the hugepage
   recovery path. [Ackerley]
 - Add back "KVM: x86/mmu: Handle guest page faults for guest_memfd with
   shared memory". [Ackerley]
 - Rework the selftest flags testcase to query MMAP support for a given VM
   type instead of hardcoding expectations in the test. [Sean]
 - Add a testcase to verify KVM can map guest_memfd memory into the guest
   even if the userspace address in the memslot isn't (properly) mmap'd. [Sean]

v16:
 - https://lore.kernel.org/all/20250723104714.1674617-1-tabba@google.com
 - Rework and simplify Kconfig selection and dependencies.
 - Always enable guest_memfd for KVM x86 (64-bit) and arm64, which
   simplifies the enablement checks.
 - Based on kvm-x86/next: commit 33f843444e28 ("Merge branch 'vmx'").

v15:
 - https://lore.kernel.org/all/20250717162731.446579-1-tabba@google.com
 - Removed KVM_SW_PROTECTED_VM dependency on KVM_GENERIC_GMEM_POPULATE
 - Fixed some commit messages

v14:
 - https://lore.kernel.org/all/20250715093350.2584932-1-tabba@google.com
 - Fixed handling of guest faults in case of invalidation in arm64
 - Handle VNCR_EL2-triggered faults backed by guest_memfd (arm64 nested
   virt)
 - Applied suggestions from latest feedback
 - Rebase on Linux 6.16-rc6

Ackerley Tng (2):
  KVM: x86/mmu: Rename .private_max_mapping_level() to
    .gmem_max_mapping_level()
  KVM: x86/mmu: Handle guest page faults for guest_memfd with shared
    memory

Fuad Tabba (15):
  KVM: Rename CONFIG_KVM_PRIVATE_MEM to CONFIG_KVM_GUEST_MEMFD
  KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to
    CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE
  KVM: Rename kvm_slot_can_be_private() to kvm_slot_has_gmem()
  KVM: Fix comments that refer to slots_lock
  KVM: Fix comment that refers to kvm uapi header path
  KVM: x86: Enable KVM_GUEST_MEMFD for all 64-bit builds
  KVM: guest_memfd: Add plumbing to host to map guest_memfd pages
  KVM: guest_memfd: Track guest_memfd mmap support in memslot
  KVM: arm64: Refactor user_mem_abort()
  KVM: arm64: Handle guest_memfd-backed guest page faults
  KVM: arm64: nv: Handle VNCR_EL2-triggered faults backed by guest_memfd
  KVM: arm64: Enable support for guest_memfd backed memory
  KVM: Allow and advertise support for host mmap() on guest_memfd files
  KVM: selftests: Do not use hardcoded page sizes in guest_memfd test
  KVM: selftests: guest_memfd mmap() test when mmap is supported

Sean Christopherson (7):
  KVM: x86: Have all vendor neutral sub-configs depend on KVM_X86, not
    just KVM
  KVM: x86: Select KVM_GENERIC_PRIVATE_MEM directly from
    KVM_SW_PROTECTED_VM
  KVM: x86: Select TDX's KVM_GENERIC_xxx dependencies iff
    CONFIG_KVM_INTEL_TDX=y
  KVM: x86/mmu: Hoist guest_memfd max level/order helpers "up" in mmu.c
  KVM: x86/mmu: Enforce guest_memfd's max order when recovering
    hugepages
  KVM: x86/mmu: Extend guest_memfd's max mapping level to shared
    mappings
  KVM: selftests: Add guest_memfd testcase to fault-in on !mmap()'d
    memory

 Documentation/virt/kvm/api.rst                |   9 +
 arch/arm64/kvm/Kconfig                        |   1 +
 arch/arm64/kvm/mmu.c                          | 203 +++++++++++----
 arch/arm64/kvm/nested.c                       |  41 ++-
 arch/x86/include/asm/kvm-x86-ops.h            |   2 +-
 arch/x86/include/asm/kvm_host.h               |   6 +-
 arch/x86/kvm/Kconfig                          |  26 +-
 arch/x86/kvm/mmu/mmu.c                        | 142 ++++++-----
 arch/x86/kvm/mmu/mmu_internal.h               |   2 +-
 arch/x86/kvm/mmu/tdp_mmu.c                    |   2 +-
 arch/x86/kvm/svm/sev.c                        |   6 +-
 arch/x86/kvm/svm/svm.c                        |   2 +-
 arch/x86/kvm/svm/svm.h                        |   4 +-
 arch/x86/kvm/vmx/main.c                       |   7 +-
 arch/x86/kvm/vmx/tdx.c                        |   5 +-
 arch/x86/kvm/vmx/x86_ops.h                    |   2 +-
 arch/x86/kvm/x86.c                            |  11 +
 include/linux/kvm_host.h                      |  38 +--
 include/uapi/linux/kvm.h                      |   2 +
 tools/testing/selftests/kvm/Makefile.kvm      |   1 +
 .../testing/selftests/kvm/guest_memfd_test.c  | 236 ++++++++++++++++--
 virt/kvm/Kconfig                              |  15 +-
 virt/kvm/Makefile.kvm                         |   2 +-
 virt/kvm/guest_memfd.c                        |  81 +++++-
 virt/kvm/kvm_main.c                           |  12 +-
 virt/kvm/kvm_mm.h                             |   4 +-
 26 files changed, 648 insertions(+), 214 deletions(-)


base-commit: beafd7ecf2255e8b62a42dc04f54843033db3d24
-- 
2.50.1.552.g942d659e1b-goog

Sean Christopherson <seanjc@google.com> writes:

> Paolo,
>
> The arm64 patches have been Reviewed-by Marc, and AFAICT the x86 side of
> things is a go.  Barring a screwup on my end, this just needs your approval.
>
> Assuming everything looks good, it'd be helpful to get this into kvm/next
> shortly after rc1.  The x86 Kconfig changes in particular create semantic
> conflicts with in-flight series.
>
>
> Add support for host userspace mapping of guest_memfd-backed memory for VM
> types that do NOT use support KVM_MEMORY_ATTRIBUTE_PRIVATE (which isn't
> precisely the same thing as CoCo VMs, since x86's SEV-MEM and SEV-ES have
> no way to detect private vs. shared).
>
> mmap() support paves the way for several evolving KVM use cases:
>
>  * Allows VMMs like Firecracker to run guests entirely backed by
>    guest_memfd [1]. This provides a unified memory management model for
>    both confidential and non-confidential guests, simplifying VMM design.
>
>  * Enhanced Security via direct map removal: When combined with Patrick's
>    series for direct map removal [2], this provides additional hardening
>    against Spectre-like transient execution attacks by eliminating the
>    need for host kernel direct maps of guest memory.
>
>  * Lays the groundwork for *restricted* mmap() support for guest_memfd-backed
>    memory on CoCo platforms [3] that permit in-place
>    sharing of guest memory with the host.
>
> Based on kvm/queue.
>
> [1] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding
> [2] https://lore.kernel.org/all/20250221160728.1584559-1-roypat@amazon.co.uk
> [3] https://lore.kernel.org/all/20250328153133.3504118-1-tabba@google.com
>
> [...snip...]

With this version, when guest_memfd memory is mmap-ed() and faulted to
userspace, when there's a memory failure, the process does not get a
SIGBUS. Specifically, this selftest fails with "MADV_HWPOISON should
have triggered SIGBUS."

diff --git i/tools/testing/selftests/kvm/guest_memfd_test.c w/tools/testing/selftests/kvm/guest_memfd_test.c
index b86bf89a71e04..70ef75a23bb60 100644
--- i/tools/testing/selftests/kvm/guest_memfd_test.c
+++ w/tools/testing/selftests/kvm/guest_memfd_test.c
@@ -70,6 +70,10 @@ static void test_mmap_supported(int fd, size_t page_size, size_t total_size)
 
 	ret = munmap(mem, total_size);
 	TEST_ASSERT(!ret, "munmap() should succeed.");
+
+	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0,
+			total_size);
+	TEST_ASSERT(!ret, "Truncate the entire file (cleanup) should succeed.");
 }
 
 static sigjmp_buf jmpbuf;
@@ -104,6 +108,47 @@ static void test_fault_overflow(int fd, size_t page_size, size_t total_size)
 
 	ret = munmap(mem, map_size);
 	TEST_ASSERT(!ret, "munmap() should succeed.");
+
+	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0,
+			total_size);
+	TEST_ASSERT(!ret, "Truncate the entire file (cleanup) should succeed.");
+}
+
+static void test_memory_failure(int fd, size_t page_size, size_t total_size)
+{
+	struct sigaction sa_old, sa_new = {
+		.sa_handler = fault_sigbus_handler,
+	};
+	void *memory_failure_addr;
+	char *mem;
+	int ret;
+
+	mem = mmap(NULL, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+	TEST_ASSERT(mem != MAP_FAILED, "mmap() for guest_memfd should succeed.");
+
+	memset(mem, 0xaa, page_size);
+
+	memory_failure_addr = mem + page_size;
+	sigaction(SIGBUS, &sa_new, &sa_old);
+	if (sigsetjmp(jmpbuf, 1) == 0) {
+		madvise(memory_failure_addr, page_size, MADV_HWPOISON);
+		TEST_ASSERT(false, "MADV_HWPOISON should have triggered SIGBUS.");
+	}
+	sigaction(SIGBUS, &sa_old, NULL);
+
+	ret = munmap(mem, total_size);
+	TEST_ASSERT(!ret, "munmap() should succeed.");
+
+	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0,
+			total_size);
+	TEST_ASSERT(!ret, "Truncate the entire file (cleanup) should succeed.");
 }
 
 static void test_mmap_not_supported(int fd, size_t page_size, size_t total_size)
@@ -286,6 +331,7 @@ static void test_guest_memfd(unsigned long vm_type)
 	if (flags & GUEST_MEMFD_FLAG_MMAP) {
 		test_mmap_supported(fd, page_size, total_size);
 		test_fault_overflow(fd, page_size, total_size);
+		test_memory_failure(fd, page_size, total_size);
 	} else {
 		test_mmap_not_supported(fd, page_size, total_size);
 	}

Is this by design or should some new memory_failure handling be added?

Ackerley Tng <ackerleytng@google.com> writes:

> Sean Christopherson <seanjc@google.com> writes:
>
>> Paolo,
>>
>> The arm64 patches have been Reviewed-by Marc, and AFAICT the x86 side of
>> things is a go.  Barring a screwup on my end, this just needs your approval.
>>
>> Assuming everything looks good, it'd be helpful to get this into kvm/next
>> shortly after rc1.  The x86 Kconfig changes in particular create semantic
>> conflicts with in-flight series.
>>
>>
>> Add support for host userspace mapping of guest_memfd-backed memory for VM
>> types that do NOT use support KVM_MEMORY_ATTRIBUTE_PRIVATE (which isn't
>> precisely the same thing as CoCo VMs, since x86's SEV-MEM and SEV-ES have
>> no way to detect private vs. shared).
>>
>> mmap() support paves the way for several evolving KVM use cases:
>>
>>  * Allows VMMs like Firecracker to run guests entirely backed by
>>    guest_memfd [1]. This provides a unified memory management model for
>>    both confidential and non-confidential guests, simplifying VMM design.
>>
>>  * Enhanced Security via direct map removal: When combined with Patrick's
>>    series for direct map removal [2], this provides additional hardening
>>    against Spectre-like transient execution attacks by eliminating the
>>    need for host kernel direct maps of guest memory.
>>
>>  * Lays the groundwork for *restricted* mmap() support for guest_memfd-backed
>>    memory on CoCo platforms [3] that permit in-place
>>    sharing of guest memory with the host.
>>
>> Based on kvm/queue.
>>
>> [1] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding
>> [2] https://lore.kernel.org/all/20250221160728.1584559-1-roypat@amazon.co.uk
>> [3] https://lore.kernel.org/all/20250328153133.3504118-1-tabba@google.com
>>
>> [...snip...]
>
> With this version, when guest_memfd memory is mmap-ed() and faulted to
> userspace, when there's a memory failure, the process does not get a
> SIGBUS. Specifically, this selftest fails with "MADV_HWPOISON should
> have triggered SIGBUS."
>
> diff --git i/tools/testing/selftests/kvm/guest_memfd_test.c w/tools/testing/selftests/kvm/guest_memfd_test.c
> index b86bf89a71e04..70ef75a23bb60 100644
> --- i/tools/testing/selftests/kvm/guest_memfd_test.c
> +++ w/tools/testing/selftests/kvm/guest_memfd_test.c
> @@ -70,6 +70,10 @@ static void test_mmap_supported(int fd, size_t page_size, size_t total_size)
>  
>  	ret = munmap(mem, total_size);
>  	TEST_ASSERT(!ret, "munmap() should succeed.");
> +
> +	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0,
> +			total_size);
> +	TEST_ASSERT(!ret, "Truncate the entire file (cleanup) should succeed.");
>  }
>  
>  static sigjmp_buf jmpbuf;
> @@ -104,6 +108,47 @@ static void test_fault_overflow(int fd, size_t page_size, size_t total_size)
>  
>  	ret = munmap(mem, map_size);
>  	TEST_ASSERT(!ret, "munmap() should succeed.");
> +
> +	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0,
> +			total_size);
> +	TEST_ASSERT(!ret, "Truncate the entire file (cleanup) should succeed.");
> +}
> +
> +static void test_memory_failure(int fd, size_t page_size, size_t total_size)
> +{
> +	struct sigaction sa_old, sa_new = {
> +		.sa_handler = fault_sigbus_handler,
> +	};
> +	void *memory_failure_addr;
> +	char *mem;
> +	int ret;
> +
> +	mem = mmap(NULL, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> +	TEST_ASSERT(mem != MAP_FAILED, "mmap() for guest_memfd should succeed.");
> +
> +	memset(mem, 0xaa, page_size);
> +

My bad. If the above was changed from page_size to total_size, the page
would have been faulted in, and then we get a SIGBUS.

> +	memory_failure_addr = mem + page_size;
> +	sigaction(SIGBUS, &sa_new, &sa_old);
> +	if (sigsetjmp(jmpbuf, 1) == 0) {
> +		madvise(memory_failure_addr, page_size, MADV_HWPOISON);
> +		TEST_ASSERT(false, "MADV_HWPOISON should have triggered SIGBUS.");
> +	}
> +	sigaction(SIGBUS, &sa_old, NULL);
> +
> +	ret = munmap(mem, total_size);
> +	TEST_ASSERT(!ret, "munmap() should succeed.");
> +
> +	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0,
> +			total_size);
> +	TEST_ASSERT(!ret, "Truncate the entire file (cleanup) should succeed.");
>  }
>  
>  static void test_mmap_not_supported(int fd, size_t page_size, size_t total_size)
> @@ -286,6 +331,7 @@ static void test_guest_memfd(unsigned long vm_type)
>  	if (flags & GUEST_MEMFD_FLAG_MMAP) {
>  		test_mmap_supported(fd, page_size, total_size);
>  		test_fault_overflow(fd, page_size, total_size);
> +		test_memory_failure(fd, page_size, total_size);
>  	} else {
>  		test_mmap_not_supported(fd, page_size, total_size);
>  	}
>
> Is this by design or should some new memory_failure handling be added?

On 7/30/25 00:54, Sean Christopherson wrote:
> Paolo,
> 
> The arm64 patches have been Reviewed-by Marc, and AFAICT the x86 side of
> things is a go.  Barring a screwup on my end, this just needs your approval.
> 
> Assuming everything looks good, it'd be helpful to get this into kvm/next
> shortly after rc1.  The x86 Kconfig changes in particular create semantic
> conflicts with in-flight series.
> 
> 
> Add support for host userspace mapping of guest_memfd-backed memory for VM
> types that do NOT use support KVM_MEMORY_ATTRIBUTE_PRIVATE (which isn't
> precisely the same thing as CoCo VMs, since x86's SEV-MEM and SEV-ES have
> no way to detect private vs. shared).
> 
> mmap() support paves the way for several evolving KVM use cases:
> 
>   * Allows VMMs like Firecracker to run guests entirely backed by
>     guest_memfd [1]. This provides a unified memory management model for
>     both confidential and non-confidential guests, simplifying VMM design.
> 
>   * Enhanced Security via direct map removal: When combined with Patrick's
>     series for direct map removal [2], this provides additional hardening
>     against Spectre-like transient execution attacks by eliminating the
>     need for host kernel direct maps of guest memory.
> 
>   * Lays the groundwork for *restricted* mmap() support for guest_memfd-backed
>     memory on CoCo platforms [3] that permit in-place
>     sharing of guest memory with the host.
> 
> Based on kvm/queue.

Applied to kvm/next, thanks!

Paolo

> [1] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding
> [2] https://lore.kernel.org/all/20250221160728.1584559-1-roypat@amazon.co.uk
> [3] https://lore.kernel.org/all/20250328153133.3504118-1-tabba@google.com
> 
> v17:
>   - Collect reviews. [Xiaoyao, David H.]
>   - Write a better changelog for the CONFIG_KVM_GENERIC_PRIVATE_MEM =>
>     CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE rename. [Xiaoyao]
>   - Correctly gmem_max_mapping_level()'s '0' return in the right patch. [Xiaoyao]
>   - Replace call to kvm_gmem_get_pfn() with a WARN_ONCE() in the hugepage
>     recovery path. [Ackerley]
>   - Add back "KVM: x86/mmu: Handle guest page faults for guest_memfd with
>     shared memory". [Ackerley]
>   - Rework the selftest flags testcase to query MMAP support for a given VM
>     type instead of hardcoding expectations in the test. [Sean]
>   - Add a testcase to verify KVM can map guest_memfd memory into the guest
>     even if the userspace address in the memslot isn't (properly) mmap'd. [Sean]
> 
> v16:
>   - https://lore.kernel.org/all/20250723104714.1674617-1-tabba@google.com
>   - Rework and simplify Kconfig selection and dependencies.
>   - Always enable guest_memfd for KVM x86 (64-bit) and arm64, which
>     simplifies the enablement checks.
>   - Based on kvm-x86/next: commit 33f843444e28 ("Merge branch 'vmx'").
> 
> v15:
>   - https://lore.kernel.org/all/20250717162731.446579-1-tabba@google.com
>   - Removed KVM_SW_PROTECTED_VM dependency on KVM_GENERIC_GMEM_POPULATE
>   - Fixed some commit messages
> 
> v14:
>   - https://lore.kernel.org/all/20250715093350.2584932-1-tabba@google.com
>   - Fixed handling of guest faults in case of invalidation in arm64
>   - Handle VNCR_EL2-triggered faults backed by guest_memfd (arm64 nested
>     virt)
>   - Applied suggestions from latest feedback
>   - Rebase on Linux 6.16-rc6
> 
> Ackerley Tng (2):
>    KVM: x86/mmu: Rename .private_max_mapping_level() to
>      .gmem_max_mapping_level()
>    KVM: x86/mmu: Handle guest page faults for guest_memfd with shared
>      memory
> 
> Fuad Tabba (15):
>    KVM: Rename CONFIG_KVM_PRIVATE_MEM to CONFIG_KVM_GUEST_MEMFD
>    KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to
>      CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE
>    KVM: Rename kvm_slot_can_be_private() to kvm_slot_has_gmem()
>    KVM: Fix comments that refer to slots_lock
>    KVM: Fix comment that refers to kvm uapi header path
>    KVM: x86: Enable KVM_GUEST_MEMFD for all 64-bit builds
>    KVM: guest_memfd: Add plumbing to host to map guest_memfd pages
>    KVM: guest_memfd: Track guest_memfd mmap support in memslot
>    KVM: arm64: Refactor user_mem_abort()
>    KVM: arm64: Handle guest_memfd-backed guest page faults
>    KVM: arm64: nv: Handle VNCR_EL2-triggered faults backed by guest_memfd
>    KVM: arm64: Enable support for guest_memfd backed memory
>    KVM: Allow and advertise support for host mmap() on guest_memfd files
>    KVM: selftests: Do not use hardcoded page sizes in guest_memfd test
>    KVM: selftests: guest_memfd mmap() test when mmap is supported
> 
> Sean Christopherson (7):
>    KVM: x86: Have all vendor neutral sub-configs depend on KVM_X86, not
>      just KVM
>    KVM: x86: Select KVM_GENERIC_PRIVATE_MEM directly from
>      KVM_SW_PROTECTED_VM
>    KVM: x86: Select TDX's KVM_GENERIC_xxx dependencies iff
>      CONFIG_KVM_INTEL_TDX=y
>    KVM: x86/mmu: Hoist guest_memfd max level/order helpers "up" in mmu.c
>    KVM: x86/mmu: Enforce guest_memfd's max order when recovering
>      hugepages
>    KVM: x86/mmu: Extend guest_memfd's max mapping level to shared
>      mappings
>    KVM: selftests: Add guest_memfd testcase to fault-in on !mmap()'d
>      memory
> 
>   Documentation/virt/kvm/api.rst                |   9 +
>   arch/arm64/kvm/Kconfig                        |   1 +
>   arch/arm64/kvm/mmu.c                          | 203 +++++++++++----
>   arch/arm64/kvm/nested.c                       |  41 ++-
>   arch/x86/include/asm/kvm-x86-ops.h            |   2 +-
>   arch/x86/include/asm/kvm_host.h               |   6 +-
>   arch/x86/kvm/Kconfig                          |  26 +-
>   arch/x86/kvm/mmu/mmu.c                        | 142 ++++++-----
>   arch/x86/kvm/mmu/mmu_internal.h               |   2 +-
>   arch/x86/kvm/mmu/tdp_mmu.c                    |   2 +-
>   arch/x86/kvm/svm/sev.c                        |   6 +-
>   arch/x86/kvm/svm/svm.c                        |   2 +-
>   arch/x86/kvm/svm/svm.h                        |   4 +-
>   arch/x86/kvm/vmx/main.c                       |   7 +-
>   arch/x86/kvm/vmx/tdx.c                        |   5 +-
>   arch/x86/kvm/vmx/x86_ops.h                    |   2 +-
>   arch/x86/kvm/x86.c                            |  11 +
>   include/linux/kvm_host.h                      |  38 +--
>   include/uapi/linux/kvm.h                      |   2 +
>   tools/testing/selftests/kvm/Makefile.kvm      |   1 +
>   .../testing/selftests/kvm/guest_memfd_test.c  | 236 ++++++++++++++++--
>   virt/kvm/Kconfig                              |  15 +-
>   virt/kvm/Makefile.kvm                         |   2 +-
>   virt/kvm/guest_memfd.c                        |  81 +++++-
>   virt/kvm/kvm_main.c                           |  12 +-
>   virt/kvm/kvm_mm.h                             |   4 +-
>   26 files changed, 648 insertions(+), 214 deletions(-)
> 
> 
> base-commit: beafd7ecf2255e8b62a42dc04f54843033db3d24

On Wed, 27 Aug 2025 09:43:54 +0100,
Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 7/30/25 00:54, Sean Christopherson wrote:
> > Paolo,
> > 
> > The arm64 patches have been Reviewed-by Marc, and AFAICT the x86 side of
> > things is a go.  Barring a screwup on my end, this just needs your approval.
> > 
> > Assuming everything looks good, it'd be helpful to get this into kvm/next
> > shortly after rc1.  The x86 Kconfig changes in particular create semantic
> > conflicts with in-flight series.
> > 
> > 
> > Add support for host userspace mapping of guest_memfd-backed memory for VM
> > types that do NOT use support KVM_MEMORY_ATTRIBUTE_PRIVATE (which isn't
> > precisely the same thing as CoCo VMs, since x86's SEV-MEM and SEV-ES have
> > no way to detect private vs. shared).
> > 
> > mmap() support paves the way for several evolving KVM use cases:
> > 
> >   * Allows VMMs like Firecracker to run guests entirely backed by
> >     guest_memfd [1]. This provides a unified memory management model for
> >     both confidential and non-confidential guests, simplifying VMM design.
> > 
> >   * Enhanced Security via direct map removal: When combined with Patrick's
> >     series for direct map removal [2], this provides additional hardening
> >     against Spectre-like transient execution attacks by eliminating the
> >     need for host kernel direct maps of guest memory.
> > 
> >   * Lays the groundwork for *restricted* mmap() support for guest_memfd-backed
> >     memory on CoCo platforms [3] that permit in-place
> >     sharing of guest memory with the host.
> > 
> > Based on kvm/queue.
> 
> Applied to kvm/next, thanks!

Can you please create a stable branch for these patches? It is quite
likely that whatever I queue for 6.18 will conflict with that, and I'd
like to be able to resolve the conflicts myself.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Yo can

On Wed, Aug 27, 2025 at 3:08 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 27 Aug 2025 09:43:54 +0100,
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> > Applied to kvm/next, thanks!
>
> Can you please create a stable branch for these patches? It is quite
> likely that whatever I queue for 6.18 will conflict with that, and I'd
> like to be able to resolve the conflicts myself.

You can just base kvm-arm/next on kvm/next, but if you prefer I pushed
guest-memfd-mmap at https://git.kernel.org/pub/scm/virt/kvm/kvm.git/.

Paolo

On Wed, 27 Aug 2025 14:11:22 +0100,
Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> Yo can
> 
> On Wed, Aug 27, 2025 at 3:08 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 27 Aug 2025 09:43:54 +0100,
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> > > Applied to kvm/next, thanks!
> >
> > Can you please create a stable branch for these patches? It is quite
> > likely that whatever I queue for 6.18 will conflict with that, and I'd
> > like to be able to resolve the conflicts myself.
> 
> You can just base kvm-arm/next on kvm/next, but if you prefer I pushed
> guest-memfd-mmap at https://git.kernel.org/pub/scm/virt/kvm/kvm.git/.

Pulled, thanks.

	M.

-- 
Without deviation from the norm, progress is not possible.

On Wed, Aug 27, 2025, Paolo Bonzini wrote:
> On 7/30/25 00:54, Sean Christopherson wrote:
> > Paolo,
> > 
> > The arm64 patches have been Reviewed-by Marc, and AFAICT the x86 side of
> > things is a go.  Barring a screwup on my end, this just needs your approval.
> > 
> > Assuming everything looks good, it'd be helpful to get this into kvm/next
> > shortly after rc1.  The x86 Kconfig changes in particular create semantic
> > conflicts with in-flight series.
> > 
> > 
> > Add support for host userspace mapping of guest_memfd-backed memory for VM
> > types that do NOT use support KVM_MEMORY_ATTRIBUTE_PRIVATE (which isn't
> > precisely the same thing as CoCo VMs, since x86's SEV-MEM and SEV-ES have
> > no way to detect private vs. shared).
> > 
> > mmap() support paves the way for several evolving KVM use cases:
> > 
> >   * Allows VMMs like Firecracker to run guests entirely backed by
> >     guest_memfd [1]. This provides a unified memory management model for
> >     both confidential and non-confidential guests, simplifying VMM design.
> > 
> >   * Enhanced Security via direct map removal: When combined with Patrick's
> >     series for direct map removal [2], this provides additional hardening
> >     against Spectre-like transient execution attacks by eliminating the
> >     need for host kernel direct maps of guest memory.
> > 
> >   * Lays the groundwork for *restricted* mmap() support for guest_memfd-backed
> >     memory on CoCo platforms [3] that permit in-place
> >     sharing of guest memory with the host.
> > 
> > Based on kvm/queue.
> 
> Applied to kvm/next, thanks!

Thank you!

FWIW, I did separate run of the patches and came up with the same resolutions
for the arm64 changes, so I'm sure they're perfect ;-)