[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6be93d78e01906ff5c3714005170d761e5b40d41.camel@intel.com>
Date: Thu, 23 Mar 2023 22:09:45 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"Luck, Tony" <tony.luck@...el.com>,
"david@...hat.com" <david@...hat.com>,
"bagasdotme@...il.com" <bagasdotme@...il.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"Shahar, Sagi" <sagis@...gle.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"imammedo@...hat.com" <imammedo@...hat.com>,
"Gao, Chao" <chao.gao@...el.com>,
"Brown, Len" <len.brown@...el.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Huang, Ying" <ying.huang@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v10 05/16] x86/virt/tdx: Add skeleton to enable TDX on
demand
On Thu, 2023-03-23 at 06:49 -0700, Hansen, Dave wrote:
> On 3/15/23 04:10, Huang, Kai wrote:
> > I can do. Just want to make sure do you want to retry TDX_SYS_BUSY, or retry
> > TDX_RND_NO_ENTROPY (if we want to ask TDX module guys to change to return this
> > value)?
>
> I'll put it this way:
>
> Linux is going to treat TDX_SYS_BUSY like a Linux bug and assume
> Linux is doing something wrong. It'll mostly mean that
> users will see something nasty and may even cause Linux to give
> up on TDX. In other words, the TDX module shouldn't use
> TDX_SYS_BUSY for things that aren't Linux's fault.
>
> > Also, even we retry either TDX_SYS_BUSY or TDX_RND_NO_ENTROPY in common
> > seamcall() code, it doesn't handle the TDH.SYS.KEY.CONFIG, because sadly this
> > SEAMCALL returns a different error code:
> >
> > TDX_KEY_GENERATION_FAILED Failed to generate a random key. This is
> > typically caused by an entropy error of the
> > CPU's random number generator, and may
> > be impacted by RDSEED, RDRAND or PCONFIG
> > executing on other LPs. The operation should be
> > retried.
>
> Sounds like we should just replace TDX_KEY_GENERATION_FAILED with
> TDX_RND_NO_ENTROPY in cases where key generation fails because of a lack
> of entropy.
Thanks for feedback.
I'll do following, please let me know for any comments in case I have any
misunderstanding.
1) In TDH.SYS.INIT, ask TDX module team to return TDX_RND_NO_ENTROPY instead of
TDX_SYS_BUSY when running out of entropy.
2) In TDH.SYS.KEY.CONFIG, ask TDX module to return TDX_RND_NO_ENTROPY instead of
TDX_KEY_GENERATION_FAILED when running out of entropy. Whether
TDX_KEY_GENERATION_FAILED should be still kept is up to TDX module team
(because it looks running concurrent PCONFIGs is also related).
3) Ask TDX module to always return TDX_RND_NO_ENTROPY in _ALL_ SEAMCALLs and
keep this behaviour for future TDX modules too.
4) In the common seamcall(), retry on TDX_RND_NO_ENTROPY.
In terms of how many times to retry, I will use a fixed value for now, similar
to the kernel code below:
#define RDRAND_RETRY_LOOPS 10
/* Unconditional execution of RDRAND and RDSEED */
static inline bool __must_check rdrand_long(unsigned long *v)
{
bool ok;
unsigned int retry = RDRAND_RETRY_LOOPS;
do {
asm volatile("rdrand %[out]"
CC_SET(c)
: CC_OUT(c) (ok), [out] "=r" (*v));
if (ok)
return true;
} while (--retry);
return false;
}
Powered by blists - more mailing lists