Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2

[Michael Roth <michael.roth@amd.com>]

On Wed, Apr 01, 2026 at 03:38:12PM -0700, Ackerley Tng wrote:
> Michael Roth <michael.roth@amd.com> 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.

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
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/

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

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

Thanks,

Mike