On Thu, 17 Jul 2025 at 17:50, Ackerley Tng <ackerleytng@xxxxxxxxxx> wrote: > > Xiaoyao Li <xiaoyao.li@xxxxxxxxx> writes: > > > On 7/17/2025 8:12 AM, Ackerley Tng wrote: > >> Xiaoyao Li <xiaoyao.li@xxxxxxxxx> writes: > >> > >>> On 7/15/2025 5:33 PM, Fuad Tabba wrote: > >>>> Introduce a new boolean member, supports_gmem, to kvm->arch. > >>>> > >>>> Previously, the has_private_mem boolean within kvm->arch was implicitly > >>>> used to indicate whether guest_memfd was supported for a KVM instance. > >>>> However, with the broader support for guest_memfd, it's not exclusively > >>>> for private or confidential memory. Therefore, it's necessary to > >>>> distinguish between a VM's general guest_memfd capabilities and its > >>>> support for private memory. > >>>> > >>>> This new supports_gmem member will now explicitly indicate guest_memfd > >>>> support for a given VM, allowing has_private_mem to represent only > >>>> support for private memory. > >>>> > >>>> Reviewed-by: Ira Weiny <ira.weiny@xxxxxxxxx> > >>>> Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx> > >>>> Reviewed-by: Shivank Garg <shivankg@xxxxxxx> > >>>> Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx> > >>>> Co-developed-by: David Hildenbrand <david@xxxxxxxxxx> > >>>> Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> > >>>> Signed-off-by: Fuad Tabba <tabba@xxxxxxxxxx> > >>> > >>> Reviewed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx> > >>> > >>> Btw, it seems that supports_gmem can be enabled for all the types of VM? > >>> > >> > >> For now, not really, because supports_gmem allows mmap support, and mmap > >> support enables KVM_MEMSLOT_GMEM_ONLY, and KVM_MEMSLOT_GMEM_ONLY will > >> mean that shared faults also get faulted from guest_memfd. > > > > No, mmap support is checked by kvm_arch_supports_gmem_mmap() which is > > independent to whether gmem is supported. > > > >> A TDX VM that wants to use guest_memfd for private memory and some other > >> backing memory for shared memory (let's call this use case "legacy CoCo > >> VMs") will not work if supports_gmem is just enabled for all types of > >> VMs, because then shared faults will also go to kvm_gmem_get_pfn(). > > > > This is not what this patch does. Please go back read this patch. > > > > This patch sets kvm->arch.supports_gmem to true for > > KVM_X86_SNP_VM/tdx/KVM_X86_SW_PROTECTED_VM. > > > > Further in patch 14, it sets kvm->arch.supports_gmem for KVM_X86_DEFAULT_VM. > > > > After this series, supports_gmem remains false only for KVM_X86_SEV_VM > > and KVM_X86_SEV_ES_VM. And I don't see why cannot enable supports_gmem > > for them. > > > > My bad, my explanation was actually for > kvm_arch_supports_gmem_mmap(). Could the confusion on this thread be > showing that the .supports_gmem is actually kind of confusing? > > If there's nothing dynamic about .supports_gmem, what have we remove the > .supports_gmem field and have kvm_arch_supports_gmem_mmap() decide based > on VM type? I do think that, in the same manner has_private_vm is a field, this should also be a field, and for the same reasons. It would confuse things (in x86) having one be dynamic. As David said, let's not nitpick this :) Cheers, /fuad > >> This will be cleaned up when guest_memfd supports conversion > >> (guest_memfd stage 2). There, a TDX VM will have .supports_gmem = true. > >> > >> With guest_memfd stage-2 there will also be a > >> KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING. > >> KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING defaults to false, so for legacy > >> CoCo VMs, shared faults will go to the other non-guest_memfd memory > >> source that is configured in userspace_addr as before. > >> > >> With guest_memfd stage-2, KVM_MEMSLOT_GMEM_ONLY will direct all EPT > >> faults to kvm_gmem_get_pfn(), but KVM_MEMSLOT_GMEM_ONLY will only be > >> allowed if KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING is true. TDX VMs > >> wishing to use guest_memfd as the only source of memory for the guest > >> should set KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING to true before > >> creating the guest_memfd. > >> > >>> Even without mmap support, allow all the types of VM to create > >>> guest_memfd seems not something wrong. It's just that the guest_memfd > >>> allocated might not be used, e.g., for KVM_X86_DEFAULT_VM. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> p
