[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <141def31-dcbb-70ae-2935-4fb06a986036@intel.com>
Date: Thu, 23 Mar 2023 06:49:28 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Huang, Kai" <kai.huang@...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>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"Shahar, Sagi" <sagis@...gle.com>,
"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 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.
Powered by blists - more mailing lists