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.
