On 8/13/26 23:23, Ackerley Tng wrote:
> "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:

No, I was trying to understand the impact :)

IIUC, a distribution that would have to support both would simply enable
CONFIG_KVM_VM_MEMORY_ATTRIBUTES, and the module parameter would have to be used
to select the mode of operation.

I guess that's good enough!

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

Yeah, I don't think we need a doc update.

-- 
Cheers,

David

Reply via email to