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?
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.
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/ ?
check (NULL @kvm) over-reporting support on arm64.
I think arm64 won't define CONFIG_KVM_VM_MEMORY_ATTRIBUTES? 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. 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?
Give architectures full control over overriding the default definition
of kvm_arch_has_private_mem() by removing the coupling with
CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
In a later patch, kvm_arch_has_private_mem() will be defined based on
whether architectural features are compiled in, and made orthogonal to
CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
