Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 30 Nov 2023 08:55:59 +0100
From:   Borislav Petkov <bp@alien8.de>
To:     "Reshetova, Elena" <elena.reshetova@intel.com>
Cc:     Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>,
        "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
Message-ID: <20231130075559.GAZWhAD5ScHoxbbTxL@fat_crate.local>
References: <20231122170106.270266-1-jpiotrowski@linux.microsoft.com>
 <0799b692-4b26-4e00-9cec-fdc4c929ea58@linux.microsoft.com>
 <20231129164049.GVZWdpkVlc8nUvl/jx@fat_crate.local>
 <DM8PR11MB575085570AF48AF4690986EDE782A@DM8PR11MB5750.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <DM8PR11MB575085570AF48AF4690986EDE782A@DM8PR11MB5750.namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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=E2=80=99t know if AMD architecture would support all this spectru=
m of
> the guests through.

I hear threats...

> 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.

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.

Thx.

--=20
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette