[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a2dd102-2ad9-4bbd-a5f7-5994de3870ae@suse.com>
Date: Thu, 12 Sep 2024 11:04:12 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>, Nikolay Borisov
<nik.borisov@...e.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>,
seanjc@...gle.com, pbonzini@...hat.com, kvm@...r.kernel.org
Cc: kai.huang@...el.com, isaku.yamahata@...il.com,
tony.lindgren@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/25] KVM: TDX: Initialize KVM supported capabilities
when module setup
On 5.09.24 г. 16:36 ч., Xiaoyao Li wrote:
> On 9/4/2024 7:58 PM, Nikolay Borisov wrote:
>>
>>
>> On 13.08.24 г. 1:48 ч., Rick Edgecombe wrote:
>>> From: Xiaoyao Li <xiaoyao.li@...el.com>
>>>
>>> While TDX module reports a set of capabilities/features that it
>>> supports, what KVM currently supports might be a subset of them.
>>> E.g., DEBUG and PERFMON are supported by TDX module but currently not
>>> supported by KVM.
>>>
>>> Introduce a new struct kvm_tdx_caps to store KVM's capabilities of TDX.
>>> supported_attrs and suppported_xfam are validated against fixed0/1
>>> values enumerated by TDX module. Configurable CPUID bits derive from TDX
>>> module plus applying KVM's capabilities (KVM_GET_SUPPORTED_CPUID),
>>> i.e., mask off the bits that are configurable in the view of TDX module
>>> but not supported by KVM yet.
>>>
>>> KVM_TDX_CPUID_NO_SUBLEAF is the concept from TDX module, switch it to 0
>>> and use KVM_CPUID_FLAG_SIGNIFCANT_INDEX, which are the concept of KVM.
>>>
>>> Signed-off-by: Xiaoyao Li <xiaoyao.li@...el.com>
>>> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
>>> ---
>>> uAPI breakout v1:
>>> - Change setup_kvm_tdx_caps() to use the exported 'struct tdx_sysinfo'
>>> pointer.
>>> - Change how to copy 'kvm_tdx_cpuid_config' since 'struct tdx_sysinfo'
>>> doesn't have 'kvm_tdx_cpuid_config'.
>>> - Updates for uAPI changes
>>> ---
>>> arch/x86/include/uapi/asm/kvm.h | 2 -
>>> arch/x86/kvm/vmx/tdx.c | 81 +++++++++++++++++++++++++++++++++
>>> 2 files changed, 81 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/include/uapi/asm/kvm.h
>>> b/arch/x86/include/uapi/asm/kvm.h
>>> index 47caf508cca7..c9eb2e2f5559 100644
>>> --- a/arch/x86/include/uapi/asm/kvm.h
>>> +++ b/arch/x86/include/uapi/asm/kvm.h
>>> @@ -952,8 +952,6 @@ struct kvm_tdx_cmd {
>>> __u64 hw_error;
>>> };
>>> -#define KVM_TDX_CPUID_NO_SUBLEAF ((__u32)-1)
>>> -
>>> struct kvm_tdx_cpuid_config {
>>> __u32 leaf;
>>> __u32 sub_leaf;
>>> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
>>> index 90b44ebaf864..d89973e554f6 100644
>>> --- a/arch/x86/kvm/vmx/tdx.c
>>> +++ b/arch/x86/kvm/vmx/tdx.c
>>> @@ -31,6 +31,19 @@ static void __used tdx_guest_keyid_free(int keyid)
>>> ida_free(&tdx_guest_keyid_pool, keyid);
>>> }
>>> +#define KVM_TDX_CPUID_NO_SUBLEAF ((__u32)-1)
>>> +
>>> +struct kvm_tdx_caps {
>>> + u64 supported_attrs;
>>> + u64 supported_xfam;
>>> +
>>> + u16 num_cpuid_config;
>>> + /* This must the last member. */
>>> + DECLARE_FLEX_ARRAY(struct kvm_tdx_cpuid_config, cpuid_configs);
>>> +};
>>> +
>>> +static struct kvm_tdx_caps *kvm_tdx_caps;
>>> +
>>> static int tdx_get_capabilities(struct kvm_tdx_cmd *cmd)
>>> {
>>> const struct tdx_sysinfo_td_conf *td_conf = &tdx_sysinfo->td_conf;
>>> @@ -131,6 +144,68 @@ int tdx_vm_ioctl(struct kvm *kvm, void __user
>>> *argp)
>>> return r;
>>> }
>>> +#define KVM_SUPPORTED_TD_ATTRS (TDX_TD_ATTR_SEPT_VE_DISABLE)
>>
>> Why isn't TDX_TD_ATTR_DEBUG added as well?
>
> Because so far KVM doesn't support all the features of a DEBUG TD for
> userspace. e.g., KVM doesn't provide interface for userspace to
> read/write private memory of DEBUG TD.
But this means that you can't really run a TDX with SEPT_VE_DISABLE
disabled for debugging purposes, so perhaps it might be necessary to
rethink the condition allowing SEPT_VE_DISABLE to be disabled. Without
the debug flag and SEPT_VE_DISABLE disabled the code refuses to start
the VM, what if one wants to debug some SEPT issue by having an oops
generated inside the vm ?
>
>> <snip>
>
>
Powered by blists - more mailing lists