RE: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init

From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Borislav Petkov <bp@alien8.de>,
	Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
Cc: "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"tim.gardner@canonical.com" <tim.gardner@canonical.com>,
	"roxana.nicolescu@canonical.com" <roxana.nicolescu@canonical.com>,
	"cascardo@canonical.com" <cascardo@canonical.com>,
	"kys@microsoft.com" <kys@microsoft.com>,
	"haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>,
	"sashal@kernel.org" <sashal@kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Michael Kelley <mhkelley58@gmail.com>,
	Nikolay Borisov <nik.borisov@suse.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"Cui, Dexuan" <decui@microsoft.com>
Subject: RE: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init
Date: Thu, 30 Nov 2023 08:31:03 +0000	[thread overview]
Message-ID: <DM8PR11MB575049E0C9F36001F0F374CEE782A@DM8PR11MB5750.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20231130075559.GAZWhAD5ScHoxbbTxL@fat_crate.local>

> On Thu, Nov 30, 2023 at 07:08:00AM +0000, Reshetova, Elena wrote:
> > ...
> > 3. Normal TDX 1.0 guest that is unaware that it runs in partitioned
> >    environment
> > 4. and so on
> 
> There's a reason I call it a virt zoo.
> 
> > I don’t know if AMD architecture would support all this spectrum of
> > the guests through.
> 
> I hear threats...

No threats whatsoever, I just truly don’t know details of SEV architecture
on this and how it envisioned to operate under this nesting scenario.
I raised this point to see if we can build the common understanding 
on this. My personal understanding (please correct me) was that SEV
would also allow different types of L2 guests, so I think we should be
aligning on this.  

> 
> > Instead we should have a flexible way for the L2 guest to discover
> > the virt environment it runs in (as modelled by L1 VMM) and the
> > baseline should not to assume it is a TDX or SEV guest, but assume
> > this is some special virt guest (or legacy guest, whatever approach
> > is cleaner) and expose additional interfaces to it.
> 
> You can do flexible all you want but all that guest zoo is using the
> kernel. The same code base which boots on gazillion incarnations of real
> hardware. And we have trouble keeping that code base clean already.

Fully agree, I wasn’t objecting this. What I was objecting is to make
explicit assumptions on what the L2 guest under TDX partitioning is. 

> 
> Now, all those weird guests come along, they're more or less
> "compatible" but not fully. So they have to do an exception here,
> disable some feature there which they don't want/support/cannot/bla. Or
> they use a paravisor which does *some* of the work for them so that
> needs to be accomodated too.
> 
> And so they start sprinkling around all those "differences" around the
> kernel. And turn it into an unmaintainable mess. We've been here before
> - last time it was called "if (XEN)"... and we're already getting there
> again only with two L1 encrypted guests technologies. I'm currently
> working on trimming down some of the SEV mess we've already added...
> 
> So - and I've said this a bunch of times already - whatever guest type
> it is, its interaction with the main kernel better be properly designed
> and abstracted away so that it doesn't turn into a mess.

Yes, agree, so what are our options and overall strategy on this? 
We can try to push as much as possible complexity into L1 VMM in this
scenario to keep the guest kernel almost free from these sprinkling differences.
Afterall the L1 VMM can emulate whatever it wants for the guest.
We can also see if there is a true need to add another virtualization
abstraction here, i.e. "nested encrypted guest". But to justify this one
we need to have usecases/scenarios where L1 VMM actually cannot run
L2 guest (legacy or TDX enabled) as it is. 
@Jeremi Piotrowski do you have such usecase/scenarios you can describe?

Any other options we should be considering as overall strategy? 

Best Regards,
Elena.

> 
> Thx.
> 
> --
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette