"David Hildenbrand (Arm)" <[email protected]> writes:

> On 8/7/26 23:52, Ackerley Tng via B4 Relay wrote:
>> From: Ackerley Tng <[email protected]>
>>
>>
>> [...snip...]
>>
>> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
>> index abb108886733a..2c3c22aeafa54 100644
>> --- a/arch/x86/kvm/Kconfig
>> +++ b/arch/x86/kvm/Kconfig
>> @@ -81,13 +81,21 @@ config KVM_WERROR
>>        If in doubt, say "N".
>>
>>  config KVM_VM_MEMORY_ATTRIBUTES
>> -    bool
>> +    bool "Enable per-VM PRIVATE vs. SHARED attributes (for CoCo VMs)"
>> +    depends on KVM_SW_PROTECTED_VM || KVM_INTEL_TDX || KVM_AMD_SEV
>> +    help
>> +      Enable support for tracking PRIVATE vs. SHARED memory using per-VM
>> +      memory attributes.  Using per-VM attributes is deprecated in favor of
>> +      tracking PRIVATE state in guest_memfd.  Select this if you need to run
>> +      CoCo VMs using a VMM that doesn't support guest_memfd memory
>> +      attributes.
>> +
>> +      If unsure, say N.
>
> Hm, does that imply that a distribution that must support both, cannot ship a
> single kernel?
>

Did you mean this as a documentation comment? Should the above read:

        help
          Enable support for tracking PRIVATE vs. SHARED memory using per-VM
          memory attributes.  Using per-VM attributes is deprecated in favor of
          tracking PRIVATE state in guest_memfd.  Select this if you need to run
          CoCo VMs using a VMM that doesn't support guest_memfd memory
-         attributes.
+         attributes. Select this to defer selection of where PRIVATE vs. SHARED
+         attributes are tracked to KVM module load time, where
+         gmem_in_place_conversion can be specified as a module parameter.

          If unsure, say N.

I think we should do _without_ the above clarification since using VM
memory attributes for shared/private status is intended to be
deprecated.

Is it fair to say distributions should not support both, and if they
_must_ support both, they need to read code to figure this out?

> --
> Cheers,
>
> David

Reply via email to