Received-SPF: pass (google.com: domain of linux-kernel+bounces-71719-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 19 Feb 2024 18:57:16 +0200
From: "Shutemov, Kirill" <kirill.shutemov@intel.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: "Reshetova, Elena" <elena.reshetova@intel.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, 
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, 
	"Williams, Dan J" <dan.j.williams@intel.com>, Michael Roth <michael.roth@amd.com>, 
	Ashish Kalra <ashish.kalra@amd.com>, "Dong, Eddie" <eddie.dong@intel.com>, 
	Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
Subject: Re: [PATCH 00/11] Provide SEV-SNP support for running under an SVSM
Message-ID: <fjiqqn6biwrtaye57dbhxk43jrbvh42cywcmt73zzp2nusmglu@ipb2fdxusyqm>
References: <cover.1706307364.git.thomas.lendacky@amd.com>
 <DM8PR11MB575087DCCB069C723BBE1B47E7482@DM8PR11MB5750.namprd11.prod.outlook.com>
 <447b491f-ae1a-85db-a862-0a2b999cd0d4@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <447b491f-ae1a-85db-a862-0a2b999cd0d4@amd.com>

On Fri, Feb 16, 2024 at 01:46:41PM -0600, Tom Lendacky wrote:
> > 4. Define a new guest abstraction/guest type that would be used for
> > !VMPL0/L2 guest. This allows in the future to define a unified L2 <-> L1/VMPL!0
> > <-> VMPL0 communication interface that underneath would use Intel
> > TDX/AMD SEV-SNP specified communication primitives. Out of existing Linux code,
> > this approach is followed to some initial degree by MSFT Hyper-V implementation [2].
> > It defines a new type of virtualized guest with its own initialization path and callbacks in
> >   x86_platform.guest/hyper.*. However, in our understanding noone has yet
> > attempted to define a unified abstraction for such guest, as well as unified interface.
> > AMD SEV-SNP has defined in [4] a VMPL0 <--> !VMPL0 communication interface
> >   which is AMD specific.
> 
> Can TDX create a new protocol within the SVSM that it could use?

Sure we can. But it contributes to virtualization zoo. The situation is
bad as it is. Ideally we would have a single SVSM guest type instead of
SVSM/TDX and SVSM/SEV.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov