Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 5 Oct 2021 20:42:18 -0700
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc:     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>,
        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>,
        Dave Hansen <dave.hansen@intel.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>,
        Sean Christopherson <seanjc@google.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 03/11] x86/cpufeatures: Add TDX Guest CPU feature
Message-ID: <20211006034218.ynamwigsvpgad7sr@treble>
References: <20211005025205.1784480-1-sathyanarayanan.kuppuswamy@linux.intel.com>
 <20211005025205.1784480-4-sathyanarayanan.kuppuswamy@linux.intel.com>
 <20211005210423.yfftpxxmj3cjprtv@treble>
 <15a07997-2659-6be1-b8a3-da57e72562b5@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <15a07997-2659-6be1-b8a3-da57e72562b5@linux.intel.com>
Precedence: bulk

On Tue, Oct 05, 2021 at 02:41:35PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> 
> 
> On 10/5/21 2:04 PM, Josh Poimboeuf wrote:
> > On Mon, Oct 04, 2021 at 07:51:57PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > > @@ -495,6 +496,13 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
> > >   	copy_bootdata(__va(real_mode_data));
> > > +	/*
> > > +	 * tdx_early_init() has dependency on command line parameters.
> > > +	 * So the order of calling it should be after copy_bootdata()
> > > +	 * (in which command line parameter is initialized).
> > > +	 */
> > > +	tdx_early_init();
> > 
> > Which cmdline parameters are those?
> 
> We have few debug command line options like tdx_forced (force TDX
> initialization) and tdx_disable_filter (Disables TDX device filter
> support). Support for these options have not been posted out (waiting
> to merge the initial support patches first). Since we need to access
> command line options, we want to follow the above calling order.

But until if/when those cmdline options are added, the comment is plain
wrong.  At the very least, it should state the present state of things,
i.e. that a future dependency on cmdline parameters is expected.

> > > +/*
> > > + * Allocate it in the data region to avoid zeroing it during
> > > + * BSS initialization. It is mainly used in cc_platform_has()
> > > + * call during early boot call.
> > > + */
> > > +u64 __section(".data") is_tdx_guest = 0;
> > 
> > Or you could just give it a -1 value here to avoid the section
> > annotation.  Not sure why it needs 64 bits, any reason it can't just be
> > bool?
> 
> It can be bool. I can fix this in next version.

Ok.  maybe something like

  bool is_tdx_guest = true;

along with the comment clarifying why the nonzero initializer is needed.

> > > +static void __init is_tdx_guest_init(void)
> > > +{
> > > +	u32 eax, sig[3];
> > > +
> > > +	if (cpuid_eax(0) < TDX_CPUID_LEAF_ID) {
> > > +		is_tdx_guest = 0;
> > > +		return;
> > > +	}
> > > +
> > > +	cpuid_count(TDX_CPUID_LEAF_ID, 0, &eax, &sig[0], &sig[2], &sig[1]);
> > > +
> > > +	is_tdx_guest = !memcmp("IntelTDX    ", sig, 12);
> > > +}
> > > +
> > > +void __init tdx_early_init(void)
> > > +{
> > > +	is_tdx_guest_init();
> > > +
> > > +	if (!is_tdx_guest)
> > > +		return;
> > > +
> > > +	setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
> > > +
> > > +	pr_info("Guest initialized\n");
> > > +}
> > 
> > What's the point of having both 'is_tdx_guest' and
> > X86_FEATURE_TDX_GUEST?  Are they not redundant?
> 
> is_tdx_guest was mainly introduced to support cc_platform_has()
> API in early boot calls (similar to sme_me_mask in AMD code).
> Regarding FEATURE flag it will be useful for userspace tools to
> check the TDX feature support.

FEATURE flags can also be checked in the kernel, with boot_cpu_has().
Or am I missing something?

-- 
Josh