[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <148dec1f2d895581f4fec63359e475013ad40c6d.camel@intel.com>
Date: Thu, 15 Aug 2024 23:46:00 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>
CC: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "kvm@...r.kernel.org"
<kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/25] TDX vCPU/VM creation
On Thu, 2024-08-15 at 08:20 +0300, Tony Lindgren wrote:
> We can generate a TDX suitable default CPUID configuration by adding
> KVM_GET_SUPPORTED_TDX_CPUID. This would handled similar to the existing
> KVM_GET_SUPPORTED_CPUID and KVM_GET_SUPPORTED_HV_CPUID.
What problem are you suggesting to solve with it? To give something to userspace
to say "please filter these out yourself?"
From the thread with Sean on this series, it seems maybe we won't need the
filtering in any case.
Sorry if I missed your point. KVM_GET_SUPPORTED_HV_CPUID only returns a few
extra entries associated with HV, right? I'm not following the connection to
what TDX needs here.
>
> Or are there some reasons to avoid adding this?
Powered by blists - more mailing lists