linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.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, Dexuan Cui <decui@microsoft.com>,
	linux-hyperv@vger.kernel.org, stefan.bader@canonical.com,
	tim.gardner@canonical.com, roxana.nicolescu@canonical.com,
	cascardo@canonical.com, kys@microsoft.com,
	haiyangz@microsoft.com, wei.liu@kernel.org, sashal@kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init
Date: Fri, 24 Nov 2023 11:31:44 +0100	[thread overview]
Message-ID: <9f550947-9d13-479c-90c4-2e3f7674afee@linux.microsoft.com> (raw)
In-Reply-To: <20231123135846.pakk44rqbbi7njmb@box.shutemov.name>

On 23/11/2023 14:58, Kirill A. Shutemov wrote:
> On Wed, Nov 22, 2023 at 06:01:04PM +0100, Jeremi Piotrowski wrote:
>> 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.
>>
>> We want the kernel to have X86_FEATURE_TDX_GUEST set for all TDX guests so we
>> need to check these additional CPUID bits, but we skip further initialization
>> in the function as we aren't guaranteed access to TDX module calls.
> 
> I don't follow. The idea of partitioning is that L2 OS can be
> unenlightened and have no idea if it runs indide of TD. But this patch
> tries to enumerate TDX anyway.
> 
> Why?
> 

That's not the only idea of partitioning. Partitioning provides different privilege
levels within the TD, and unenlightened L2 OS can be made to work but are inefficient.
In our case Linux always runs enlightened (both with and without TD partitioning), and
uses TDX functionality where applicable (TDX vmcalls, PTE encryption bit).

There have been long discussions on LKML about how CoCo features should be supported,
I've followed most of them and I believe we've converged on: the kernel is fully
aware what kind of guest it is (SNP/TDX) and uses CC_ATTR_XXX to check for specific
SNP/TDX features.

Right now the guest with TD partitioning is missing out on X86_FEATURE_TDX_GUEST.
That's why this patch tries to enumerate TDX.

I have posted an alternate version of this patch for discussion here:
https://lore.kernel.org/lkml/0799b692-4b26-4e00-9cec-fdc4c929ea58@linux.microsoft.com/

  reply	other threads:[~2023-11-24 10:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 17:01 [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init Jeremi Piotrowski
2023-11-22 17:01 ` [PATCH v1 2/3] x86/coco: Disable TDX module calls when TD partitioning is active Jeremi Piotrowski
2023-11-23 14:13   ` Kirill A. Shutemov
2023-11-24 10:38     ` Jeremi Piotrowski
2023-11-29 10:37       ` Huang, Kai
2023-12-01 15:27         ` Jeremi Piotrowski
2023-11-22 17:01 ` [PATCH v1 3/3] x86/tdx: Provide stub tdx_accept_memory() for non-TDX configs Jeremi Piotrowski
2023-11-23 14:11   ` Kirill A. Shutemov
2023-11-24 10:00     ` Jeremi Piotrowski
2023-11-22 17:19 ` [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init Jeremi Piotrowski
2023-11-29 16:40   ` Borislav Petkov
2023-11-30  7:08     ` Reshetova, Elena
2023-11-30  7:55       ` Borislav Petkov
2023-11-30  8:31         ` Reshetova, Elena
2023-11-30  9:21           ` Borislav Petkov
2023-12-04 16:44             ` Jeremi Piotrowski
2023-12-04 13:39           ` Jeremi Piotrowski
2023-12-04 19:37     ` Jeremi Piotrowski
2023-11-23 13:58 ` Kirill A. Shutemov
2023-11-24 10:31   ` Jeremi Piotrowski [this message]
2023-11-24 10:43     ` Kirill A. Shutemov
2023-11-24 11:04       ` Jeremi Piotrowski
2023-11-24 13:33         ` Kirill A. Shutemov
2023-11-24 16:19           ` Jeremi Piotrowski
2023-11-29  4:36             ` Huang, Kai
2023-12-01 16:16               ` Jeremi Piotrowski
2023-12-05 13:26                 ` Huang, Kai
2023-12-06 18:47                   ` Jeremi Piotrowski
2023-12-07 12:58                     ` Huang, Kai
2023-12-07 17:21                       ` Jeremi Piotrowski
2023-12-07 19:35                         ` Jeremi Piotrowski
2023-12-08 10:51                           ` Huang, Kai
2023-12-07 17:36                     ` Reshetova, Elena
2023-12-08 12:45                       ` Jeremi Piotrowski
2023-12-04  9:17 ` Reshetova, Elena
2023-12-04 19:07   ` Jeremi Piotrowski
2023-12-05 10:54     ` Kirill A. Shutemov
2023-12-06 17:49       ` Jeremi Piotrowski
2023-12-06 22:54         ` Kirill A. Shutemov
2023-12-07 17:06           ` Jeremi Piotrowski
2023-12-07 20:56             ` Kirill A. Shutemov
2023-12-05 13:24     ` Reshetova, Elena

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f550947-9d13-479c-90c4-2e3f7674afee@linux.microsoft.com \
    --to=jpiotrowski@linux.microsoft.com \
    --cc=bp@alien8.de \
    --cc=cascardo@canonical.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhkelley58@gmail.com \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=peterz@infradead.org \
    --cc=roxana.nicolescu@canonical.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stefan.bader@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tim.gardner@canonical.com \
    --cc=wei.liu@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).