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.
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.
