[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB575090573031AD9888D4738AE786A@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Mon, 4 Dec 2023 09:17:29 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Borislav Petkov" <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Michael Kelley <mhkelley58@...il.com>,
Nikolay Borisov <nik.borisov@...e.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Tom Lendacky <thomas.lendacky@....com>,
"x86@...nel.org" <x86@...nel.org>,
"Cui, Dexuan" <decui@...rosoft.com>
CC: "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"stefan.bader@...onical.com" <stefan.bader@...onical.com>,
"tim.gardner@...onical.com" <tim.gardner@...onical.com>,
"roxana.nicolescu@...onical.com" <roxana.nicolescu@...onical.com>,
"cascardo@...onical.com" <cascardo@...onical.com>,
"kys@...rosoft.com" <kys@...rosoft.com>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"sashal@...nel.org" <sashal@...nel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early
TDX init
> Check for additional CPUID bits to identify TDX guests running with Trust
> Domain (TD) partitioning enabled. TD partitioning is like nested virtualization
> inside the Trust Domain so there is a L1 TD VM(M) and there can be L2 TD VM(s).
>
> In this arrangement we are not guaranteed that the TDX_CPUID_LEAF_ID is
> visible
> to Linux running as an L2 TD VM. This is because a majority of TDX facilities
> are controlled by the L1 VMM and the L2 TDX guest needs to use TD partitioning
> aware mechanisms for what's left. So currently such guests do not have
> X86_FEATURE_TDX_GUEST set.
Back to this concrete patch. Why cannot L1 VMM emulate the correct value of
the TDX_CPUID_LEAF_ID to L2 VM? It can do this per TDX partitioning arch.
How do you handle this and other CPUID calls call currently in L1? Per spec,
all CPUIDs calls from L2 will cause L2 --> L1 exit, so what do you do in L1?
Given that you do that simple emulation, you already end up with TDX guest
code being activated. Next you can check what features you wont be able to
provide in L1 and create simple emulation calls for the TDG calls that must be
supported and cannot return error. The biggest TDG call (TDVMCALL) is already
direct call into L0 VMM, so this part doesn’t require L1 VMM support.
Until we really see what breaks with this approach, I don’t think it is worth to
take in the complexity to support different L1 hypervisors view on partitioning.
Best Regards,
Elena.
Powered by blists - more mailing lists