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

[Xiaoyao Li]

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.