On Wed, Apr 15, 2026 at 01:20:41PM -0500, Michael Roth wrote: > On Tue, Apr 14, 2026 at 06:37:00PM -0500, Michael Roth wrote: > > On Wed, Apr 01, 2026 at 03:38:12PM -0700, Ackerley Tng wrote: > > > Michael Roth <[email protected]> writes: > > > > > > > > > > > [...snip...] > > > > > > > >> static unsigned long kvm_get_vm_memory_attributes(struct kvm *kvm, > > > >> gfn_t gfn) > > > >> { > > > >> @@ -2635,6 +2625,8 @@ static int > > > >> kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm, > > > >> return -EINVAL; > > > >> if (!PAGE_ALIGNED(attrs->address) || !PAGE_ALIGNED(attrs->size)) > > > >> return -EINVAL; > > > >> + if (attrs->error_offset) > > > >> + return -EINVAL; > > > >> for (i = 0; i < ARRAY_SIZE(attrs->reserved); i++) { > > > >> if (attrs->reserved[i]) > > > >> return -EINVAL; > > > >> @@ -4983,6 +4975,11 @@ static int > > > >> kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > > >> return 1; > > > >> case KVM_CAP_GUEST_MEMFD_FLAGS: > > > >> return kvm_gmem_get_supported_flags(kvm); > > > >> + case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES: > > > >> + if (vm_memory_attributes) > > > >> + return 0; > > > >> + > > > >> + return kvm_supported_mem_attributes(kvm); > > > > > > > > Based on the discussion from the PUCK call this morning, > > > > > > Thanks for copying the discussion here, I'll start attending PUCK to > > > catch those discussions too :) > > > > > > > it sounds like it > > > > would be a good idea to limit kvm_supported_mem_attributes() to only > > > > reporting KVM_MEMORY_ATTRIBUTE_PRIVATE if the underlying CoCo > > > > implementation has all the necessary enablement to support in-place > > > > conversion via guest_memfd. In the case of SNP, there is a > > > > documentation/parameter check in snp_launch_update() that needs to be > > > > relaxed in order for userspace to be able to pass in a NULL 'src' > > > > parameter (since, for in-place conversion, it would be initialized in > > > > place > > > > as shared memory prior to the call, since by the time kvm_gmem_poulate() > > > > it will have been set to private and therefore cannot be faulted in via > > > > GUP (and if it could, we'd be unecessarily copying the src back on top > > > > of itself since src/dst are the same). > > > > > > Could this be a separate thing? If I'm understanding you correctly, it's > > > not strictly a requirement for snp_launch_update() to first support a > > > NULL 'src' parameter before this series lands. > > > > I think we are already sync'd up on this during PUCK, but for the benefit > > of others: Sean pointed out that if we don't then we'll need to add yet > > another capability so userspace can determine when it can actually do > > in-place conversion for SNP. > > (in-place conversion for SNP during pre-launch/populate phase, I meant) > > > > > Right now, this series effectively advertises in place conversion at the > > point where KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES reports > > 'KVM_MEMORY_ATTRIBUTE_PRIVATE', so I slightly reworked the series to > > include the snp_launch_update() change prior to that point in time in > > the series. Thanks to prereqs and changes/requirements you've already > > pulled in, it's just one additional patch now: > > > > KVM: SEV: Make 'uaddr' parameter optional for KVM_SEV_SNP_LAUNCH_UPDATE > > > > I also did some minor updates (prefixed with a "[squash]" tag) to advertise > > the KVM_SET_MEMORY_ATTRIBUTES2_PRESERVED flag so it can be used by > > Though I'm not sure how we deal with it if SNP/TDX at some point become > capable of using the PRESERVED flag *after* populate... but maybe that's > too unlikely to worry about? If we wanted to address it though, we could > have both PRESERVED and PRESERVED_BEFORE_LAUNCH so they can be > enumerated separately from the start. > > > userspace for SNP/TDX in the kvm_gmem_populate() path as agreed upon > > during PUCK. > > > > The branch is here, with the patches moved to where I think they > > should remain (or be squashed in for the [squash] ones): > > > > > > https://github.com/AMDESE/linux/commits/guest_memfd-inplace-conversion-v4-snp2/
Argh! Sorry (again), I just now realized there was a typo here, this is the tree I'd intended to push (and what was described in the original email): https://github.com/AMDESE/linux/commits/guest_memfd-inplace-conversion-v4-snp3/ -Mike > > > > I've also updated the QEMU patches to use the agreed-upon API flow and > > pushed them here: > > > > https://github.com/AMDESE/qemu/commits/snp-inplace-for-v4-wip2/ > > > > To start an SNP guest with in-place conversion: > > > > qemu-system-x86 \ > > -machine q35,confidential-guest-support=sev0,memory-backend=ram1 \ > > -object sev-snp-guest,id=sev0,...,convert-in-place=true \ > > -object memory-backend-memfd,id=ram1,size=16G,share=true,reserve=false > > Sorry, that should've been: > > -object memory-backend-guest-memfd,id=ram1,size=16G,share=true,reserve=false > > > > > To start an normal non-CoCo guest backed by guest_memfd with shared memory: > > > > qemu-system-x86 \ > > -machine q35,confidential-guest-support=sev0,memory-backend=ram1 \ > > -object memory-backend-memfd,id=ram1,size=16G,share=true,reserve=false > > and: > > -object memory-backend-guest-memfd,id=ram1,size=16G,share=true,reserve=false > > (and both require kvm.vm_memory_attributes=0) > > -Mike > > > > > Thanks, > > > > Mike
