Re: [PATCH v8 02/11] x86/tdx: Introduce INTEL_TDX_GUEST config option

From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Sathyanarayanan Kuppuswamy Natarajan 
	<sathyanarayanan.nkuppuswamy@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Kuppuswamy Sathyanarayanan 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Juergen Gross <jgross@suse.com>, Deep Shah <sdeep@vmware.com>,
	VMware Inc <pv-drivers@vmware.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Peter H Anvin <hpa@zytor.com>, Tony Luck <tony.luck@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Kirill Shutemov <kirill.shutemov@linux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 02/11] x86/tdx: Introduce INTEL_TDX_GUEST config option
Date: Tue, 5 Oct 2021 14:31:39 +0000	[thread overview]
Message-ID: <YVxhy0FnMAhxe0+N@google.com> (raw)
In-Reply-To: <8a484fb1-21c5-5181-3e77-c818bcc2ffa7@intel.com>

On Tue, Oct 05, 2021, Dave Hansen wrote:
> On 10/5/21 6:29 AM, Sathyanarayanan Kuppuswamy Natarajan wrote:
> > On Mon, Oct 4, 2021 at 9:53 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> >> On 10/4/21 7:51 PM, Kuppuswamy Sathyanarayanan wrote:
> >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >>> index 2b2a9639d8ae..c42dd8a2d1f4 100644
> >>> --- a/arch/x86/Kconfig
> >>> +++ b/arch/x86/Kconfig
> >>> @@ -865,6 +865,20 @@ config ACRN_GUEST
> >>>         IOT with small footprint and real-time features. More details can be
> >>>         found inhttps://projectacrn.org/.
> >>>
> >>> +config INTEL_TDX_GUEST
> >>> +     bool "Intel Trusted Domain eXtensions Guest Support"
> >>> +     depends on X86_64 && CPU_SUP_INTEL && PARAVIRT
> >>> +     depends on SECURITY
> >>> +     select X86_X2APIC
> >> Apparently some Intel CPUs don't have the x2apic feature, since the
> >> Kconfig help text for X86_X2APIC says:
> >>
> >>           This enables x2apic support on CPUs that have this feature.
> >>
> >> so how is it safe to set/enable/select that kconfig symbol?

It's safe because the X86_X2APIC=y doesn't force x2APIC mode, it only enables
support for x2APIC mode.  If the CPU doesn't support x2APIC the kernel will use
legacy xAPIC.

That said, using select instead of depends is silly.

> >> Will the x2apic code just safely not work if the h/w feature is
> >> missing?
> > For the TDX guest, x2apic will be emulated. So it will exist in our
> > case.

That's incorrect, TDX partially virtualizes (as opposed to fully emulates) x2APIC
and thus requires the CPU to support x2APIC.

> > Even if x2apic or TDX guest is not supported by CPU, it will boot just fine.
>
> This doesn't really explain the "select X86_X2APIC", though.
> 
> You just said that TDX doesn't *require* X2APIC.

Well, TDX requires the guest to support x2APIC if the guest wants to do anything
useful.

10.9.1. Virtual APIC Mode
 * Guest TDs must use virtualized x2APIC mode. xAPIC mode (using memory mapped
   APIC access) is not allowed.
 * Guest TD attempts to RDMSR or WRMSR the IA32_APIC_BASE MSR cause a #VE to the
   guest TD. The guest TD cannot disable the APIC.