Re: [PATCH v9 03/41] KVM: Enumerate support for PRIVATE memory iff kvm_arch_has_private_mem is defined

On Thu, Aug 06, 2026, Xiaoyao Li wrote:
> On 8/6/2026 8:43 AM, Sean Christopherson wrote:
> > On Wed, Aug 05, 2026, Xiaoyao Li wrote:
> > > On 7/31/2026 4:34 AM, Ackerley Tng wrote:
> > > > I think another way to phrase this is that if we don't make this change,
> > > > say, on the foo architecture where there's no CoCo and no private mem
> > > > support, kvm_supported_mem_attributes() would return true for the !kvm
> > > > case, which is over-reporting.
> > > 
> > > Under the condition that the foo architecture enables
> > > CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
> > > 
> > > > How about this, replacing the entire changelog paragraph above:
> > > > 
> > > >     Explicitly guard reporting support for KVM_MEMORY_ATTRIBUTE_PRIVATE
> > > >     based on kvm_arch_has_private_mem being #defined. This improves
> > > >     reporting accuracy by not reporting support for
> > > >     KVM_MEMORY_ATTRIBUTE_PRIVATE when kvm_supported_mem_attributes() is
> > > >     called with kvm == NULL.
> > > 
> > > It doesn't help for the case where kvm == NULL, but help for the case where
> > > CONFIG_KVM_VM_MEMORY_ATTRIBUTES is defined but kvm_arch_has_private_mem not.
> > > 
> > > sorry for being picky. I think we can say
> > > 
> > > This improves the reporting accuracy by avoiding the case where
> > > KVM_MEMORY_ATTRIBUTE_PRIVATE is reported when kvm == null even without
> > > kvm_arch_has_private_mem being #defined.
> > 
> > How about this?
> > 
> > Explicitly guard reporting support for KVM_MEMORY_ATTRIBUTE_PRIVATE based
> > on kvm_arch_has_private_mem being #defined in anticipation of tracking
> > PRIVATE vs. SHARED state per-guest_memfd, not per-VM (to allow in-place
> > conversion).
> 
> Sorry, maybe I'm stupid. I still don't understand how to connect it to
> tracking PRIVATE vs. SHARED state per-guest_memfd.
> 
> There are two diffs in this patch, and we are talking about the second diff,
> right?

Yes, the second diff is what provides the desired change in behavior.

> If the kvm_supported_mem_attributes() will be used by gmem, I can buy the
> justification. But it won't. At least, it won't after this series.

It's not about gmem using that API, it's about non-gmem using the API when
reporting KVM_CAP_MEMORY_ATTRIBUTES.  Without the change, if KVM supports any
memory attributes, i.e. if KVM_GENERIC_MEMORY_ATTRIBUTES=y, then the below will
*incorrctly* include PRIVATE in the set of memory attributes, because
KVM_CAP_MEMORY_ATTRIBUTES reports what memory attributes are supported via the
VM-scoped KVM_SET_MEMORY_ATTRIBUTES.

#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
	case KVM_CAP_MEMORY_ATTRIBUTES:
		return kvm_supported_mem_attributes(kvm);
#endif


> 
> > guest_memfd support for memory attributes is expected to be unconditional
> > to avoid yet more macros (all architectures that support guest_memfd are
> > expected to use per-gmem attributes at some point), at which point
> > enumerating support KVM_MEMORY_ATTRIBUTE_PRIVATE based solely on memory
> > attributes being supported by KVM at-large would result in a system-scope
> 
> s/memory attributes/CONFIG_KVM_VM_MEMORY_ATTRIBUTES/ ?

No.  I mean "memory attributes" as in KVM as a whole entity, i.e. everything
linked into kvm.ko (and kvm-{amd,intel}.ko, supports memory attributes.

> > check (NULL @kvm) over-reporting support on arm64.
> 
> I think arm64 won't define CONFIG_KVM_VM_MEMORY_ATTRIBUTES?

Precisely *because* of this patch.  More at the bottom.

> So it seems to have nothing to do with arm64.
> 
> It matters for x86. After patch 20, CONFIG_KVM_VM_MEMORY_ATTRIBUTES is
> user-configurable. At that time, people can disable
> CONFIG_KVM_SW_PROTECTED_VM, CONFIG_KVM_INTEL_TDX and CONFIG_KVM_AMD_SEV, but
> enable CONFIG_KVM_VM_MEMORY_ATTRIBUTES on x86. 

No, they can't.  KVM_VM_MEMORY_ATTRIBUTES depends on one of those three being
enabled.  What am I missing?

config KVM_VM_MEMORY_ATTRIBUTES
	bool "Enable per-VM PRIVATE vs. SHARED attributes (for CoCo VMs)"
	depends on KVM_SW_PROTECTED_VM || KVM_INTEL_TDX || KVM_AMD_SEV  <======

> In this case, kvm_supported_mem_attributes() reports
> KVM_MEMORY_ATTRIBUTE_PRIVATE for system-scope query which is totally wrong. I
> think this is the case we want to prevent not something won't happen for
> arm64?

Well, yeah, because of patches like this one.  That's the whole point.  Without
this change, kvm_supports_private_mem() would be reachable if and only if
KVM_VM_MEMORY_ATTRIBUTES=y, which would prevent burying that Kconfig in x86 and
would prevent arm64 from enabling the PRIVATE memory attribute in guest_memfd.