Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp5199981pxb; Tue, 5 Oct 2021 20:43:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxAlNyNW1LyqR/kDEoVGNp0sxHEmuQ3H+JSq8txHXJar8VFYqjAVULEeWCr1xB0nIV2ZDp X-Received: by 2002:a05:6a00:26e9:b0:44c:654f:80e9 with SMTP id p41-20020a056a0026e900b0044c654f80e9mr13325046pfw.14.1633491833444; Tue, 05 Oct 2021 20:43:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633491833; cv=none; d=google.com; s=arc-20160816; b=vAsaadwiZRvzTTVH7mrmoTxNZ0RZAbbaBfAHQToAllW6JmvMjevlqd05M4VBH5CEWf Dg6UxsX9liZBvDeob/TjyDYPWrBtw51gPLY/XE4Rm9AVmbeTIs8qIEL41r068/VjFWVg QRyLRFsSfu5EBJUcZ82/2R0bIMcRIRKfB9J7IzQx6aTnp0j4dt8o/qKvRsgM7ROyX+jP PHCCz6vQ1YxSryHydSw6FfJaM6hlvOrA1T3owD16T8/PZvznRQkvAMQKz28wDZYN+ysw 1LJkhs/czTR3AT20nS9YLVW/9JVHEHqxMDvN8erTEWbKw60RYujLEU5JLfAa/f/tVdrI GOig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=cq9QM7oxz7zu5iEfX1jX73fU6cps/HcqH2m3KFDbUC8=; b=KumTCgbphjytbfIV8gQAGhcOyAP+L/lm39N8EM7HH9h4oMq5EKFAsAZs+7RkQ2km/S NayxMQaN49RHf3oKPD17MQ8oxYt7tsMqIRDFQzPzi1tuXmaGqWcfRqcloMlaWK/7r07g g/Je7eWrcsMTe9ERAX5hmhaokQQX8uS5J9X+yqVLnP+emVL/C/FIyeV6uY8i7czMMMSm CvmNy+rwFLQuGTnfPCiYkM2Ie8zB5n7jVVy8g1wqIp1TAQfGloZbMqjbJedHa+jYtEY6 G20uBYGN0omuKpXzfOVOYmaZ/rAMropRxE+t1gFLYDvoEhLJXkSEqq+gdNPTiH75ynZJ aRxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="d/9I5JW/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w14si20675565pfu.138.2021.10.05.20.43.20; Tue, 05 Oct 2021 20:43:53 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="d/9I5JW/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230363AbhJFDoT (ORCPT + 99 others); Tue, 5 Oct 2021 23:44:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:38269 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230306AbhJFDoR (ORCPT ); Tue, 5 Oct 2021 23:44:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633491746; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cq9QM7oxz7zu5iEfX1jX73fU6cps/HcqH2m3KFDbUC8=; b=d/9I5JW/veR8en2Df4HC+ojaomvcdDiytircOwOEO9glW3KzFxO5yVRwFuplv3opq0dAEZ 4Ahf/ii0BaL5EjECRl+FlZ2tLaJXalQUCm1orAUTP8HS4UBUegIXMQkpC2LJOLQsTpzC+u K0sk/45LkkbBZwzt4Rf2kW+3Hdt+uBQ= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-wsk3K_6MMGWIJNLskLh7AQ-1; Tue, 05 Oct 2021 23:42:23 -0400 X-MC-Unique: wsk3K_6MMGWIJNLskLh7AQ-1 Received: by mail-qt1-f199.google.com with SMTP id z10-20020ac83e0a000000b002a732692afaso1281978qtf.2 for ; Tue, 05 Oct 2021 20:42:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cq9QM7oxz7zu5iEfX1jX73fU6cps/HcqH2m3KFDbUC8=; b=HBhOkpbazlAc1JUwMewwSDb6z/EQcBAzVsTtz0nVHDxA85ZYWeQ3LiKxtowi8PIqkx k6ZNrkaqGbhgl26FxWiHipIL9LsDxDrjHKhXvvU1DSJ8NGZ5cyTr+2q2npzqKoWrty7k /0hF5O0vVl0AN1HKdBfCn6P1F5l315+NJHZ9V/gXyKZ6056zCL6Vb/IC6bcUjasK2+nh kFnZPogLMlso66oztETs0M01dDsxohY2XFnFcuF42oGKVWECSySj90DrBgovdhhsvxIG wPNzQLi7HzQ8PKdUvt9+xHx4r+8h4gxkf+KTOE4q46L1RypmtBpgtuPgwTXKSueOXUVz nbFg== X-Gm-Message-State: AOAM533yNRFlL92seAbg8Avz+QsaazfOp/pJrXUXVsEGHUVFj1crtLhp M+1LCiIOrFTXtyuzTZjdFoGQgm7Brwu2n/0P0fcJN08goyfWm1ayRhxbn6aDly8oIQ9yGIZ0eTM v0uMs+Z2aJVS1HyfgO1cyRTuP X-Received: by 2002:a05:622a:1993:: with SMTP id u19mr24285728qtc.168.1633491743037; Tue, 05 Oct 2021 20:42:23 -0700 (PDT) X-Received: by 2002:a05:622a:1993:: with SMTP id u19mr24285713qtc.168.1633491742832; Tue, 05 Oct 2021 20:42:22 -0700 (PDT) Received: from treble ([2600:1700:6e32:6c00::15]) by smtp.gmail.com with ESMTPSA id c139sm10834026qkg.2.2021.10.05.20.42.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 20:42:22 -0700 (PDT) Date: Tue, 5 Oct 2021 20:42:18 -0700 From: Josh Poimboeuf To: "Kuppuswamy, Sathyanarayanan" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, Paolo Bonzini , David Hildenbrand , Andrea Arcangeli , Juergen Gross , Deep Shah , VMware Inc , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Peter H Anvin , Dave Hansen , Tony Luck , Dan Williams , Andi Kleen , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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