On Wed, Jul 01, 2026, Xiaoyao Li wrote:
> On 7/1/2026 2:18 AM, Ackerley Tng wrote:
> > > > I think this patch should fully buy into in-place conversions, so we
> > > > need to also set GUEST_MEMFD_FLAG_MMAP:
> > > >
> > > > @@ -483,6 +483,7 @@ struct kvm_vm *__vm_create(struct vm_shape shape,
> > > > u32 nr_runnable_vcpus,
> > > > {
> > > > u64 nr_pages = vm_nr_pages_required(shape.mode,
> > > > nr_runnable_vcpus,
> > > > nr_extra_pages);
> > > > + enum vm_mem_backing_src_type src_type = VM_MEM_SRC_ANONYMOUS;
> > > > struct userspace_mem_region *slot0;
> > > > u64 gmem_flags = 0;
> > > > struct kvm_vm *vm;
> > > > @@ -503,10 +504,16 @@ struct kvm_vm *__vm_create(struct vm_shape
> > > > shape, u32 nr_runnable_vcpus,
> > > > */
> > > > if (is_guest_memfd_required(shape)) {
> > > > flags |= KVM_MEM_GUEST_MEMFD;
> > > > - gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED;
> > > > + gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED |
> > > > GUEST_MEMFD_FLAG_MMAP;
> > > GUEST_MEMFD_FLAG_INIT_SHARED is valid only when the memory attributes is
> > > per-gmem.
> > >
> > GUEST_MEMFD_FLAG_INIT_SHARED was introduced before guest_memfd in-place
> > conversions, so I think it's orthogonal to whether memory attributes is
> > per-gmem.
>
> But before gmem in-place conversion, i.e., per-gmem attribute,
> GUEST_MEMFD_FLAG_INIT_SHARED is not supported/valid for Coco VMs.
> > > we need to check KVM_CAP_GUEST_MEMFD_FLAGS or kvm_has_gmem_attributes.
> > I think we do want to deprecate the non-in-place-conversions setup, so
> > how about inserting a TEST_REQIRE(kvm_has_gmem_attributes) here?
No. Unless supporting out-of-place conversion requires orders of magnitude more
effort than just supporting in-place conversion, selftests should play nice with
both.
> Well, then all the TDX and SNP selftest will be skipped on the kernel with
> gmem_in_place_conversion=false.
Exactly. They'll also be unusable on previous kernels.
Deprecating per-VM PRIVATE tracking does not mean dropping support. We won't be
able to drop support for years, if ever. And so from a testing perspective, we
absolutely need to validate both models (again, within reason).
