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

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