On Wed, 27 Aug 2025 09:43:54 +0100, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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.
