From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 912BBC4320A for ; Wed, 4 Aug 2021 23:13:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 658F161029 for ; Wed, 4 Aug 2021 23:13:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235456AbhHDXOB (ORCPT ); Wed, 4 Aug 2021 19:14:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230514AbhHDXOA (ORCPT ); Wed, 4 Aug 2021 19:14:00 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BA0BC061798 for ; Wed, 4 Aug 2021 16:13:47 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id b1-20020a17090a8001b029017700de3903so6972187pjn.1 for ; Wed, 04 Aug 2021 16:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hhzTmvNlWX5cKj6uzpJv9KHQQbPrBdXTpixCjT3/PRY=; b=CljRFbd5fhdRHtTbrFsjmE9HHVOxjA6WE3njAiFdB1gI6+JOk5KVge64dGAItgJVAI fgriTirhsOb+gXeVyHe6z/iUnGJspAQ2mJhT+o2awWo0dAqLDv7Pob5x2bKcY3ihPKZm 0Gea0WZIVPuz96wmRUocfThv0ABdgr1lHO6LNxxkEhomg4GW2rF/JPa57f1KPmCSOvwg DtjxHxiXYEo06yiX5I0BAwkxeQ90Coxmon5FV2UgdsbpAd9Y91ZNftnWjVjHAvAvidfu qb0tBzwv5w6ZPv+Mx1JOhPavS5d/aOVQQrdoAZXrZCb83B+0Bra9rRoJLdbVfSGDDU58 0RFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hhzTmvNlWX5cKj6uzpJv9KHQQbPrBdXTpixCjT3/PRY=; b=WxJBzahw1dnjDegVHDFt/zL6rRbcN/VvBFdHh5e+x0J5OMgkTWVyI9SAeDGrhHbFH/ 5V+5lpo0n9WQubI/HUyIZT0W4eST7yInaa8dKMdhJKhy3QuvbcEvwZpI7suWRHEF2XgG FWuzcdd+ajDwlT1z4Swhb25fogZLbIUls7epshrLPrryyvja+mSEwsSWlmy+VreweS1m 7AZuYW+QV6+2UAxT+mq/w5rqZlrxUjtwvtevj+7k5yycCECkUuH3u9SYVhLZQICWUnZr VUNKq5W8dooE3X+A420yBMeiCioBTtzvbs9Mm7SEIIRzNr8ptshKznzWKSHYGlbduVzr WF0Q== X-Gm-Message-State: AOAM531rkfNt84rr5pJs/umNmuq4/z/wN2BJJxcTXWmBV3qAFGz7mOji DkQZCssbcM9oaF1AlDBa4NmRCQ== X-Google-Smtp-Source: ABdhPJyM4JA7mt02CDJlruQVu5XDPKIQJxwCbXXn/wTHD7VWYf0SV3iqKmzCPDVbVd+hbS+HZZvZ/Q== X-Received: by 2002:a17:90a:8404:: with SMTP id j4mr12028214pjn.66.1628118826210; Wed, 04 Aug 2021 16:13:46 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id g19sm7279988pjl.25.2021.08.04.16.13.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Aug 2021 16:13:45 -0700 (PDT) Date: Wed, 4 Aug 2021 23:13:42 +0000 From: Sean Christopherson To: Erdem Aktas Cc: Xiaoyao Li , "Yamahata, Isaku" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Connor Kuehl , x86 , open list , "open list:KERNEL VIRTUAL MACHINE (KVM)" , isaku.yamahata@gmail.com, Sean Christopherson , Kai Huang , Chao Gao Subject: Re: [RFC PATCH v2 05/69] KVM: TDX: Add architectural definitions for structures and values Message-ID: References: <1057bbfe-c73e-a182-7696-afc59a4786d8@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 04, 2021, Erdem Aktas wrote: > On Mon, Aug 2, 2021 at 6:25 AM Xiaoyao Li wrote: > > > Is this information correct and is this included in the spec? I tried > > > to find it but somehow I do not see it clearly defined. > > > > > >> +#define TDX1_NR_TDCX_PAGES 4 > > >> +#define TDX1_NR_TDVPX_PAGES 5 > > >> + > > >> +#define TDX1_MAX_NR_CPUID_CONFIGS 6 > > > Why is this just 6? I am looking at the CPUID table in the spec and > > > there are already more than 6 CPUID leaves there. > > > > This is the number of CPUID config reported by TDH.SYS.INFO. Current KVM > > only reports 6 leaves. > > I, personally, still think that it should be enumerated, rather than > hardcoded. It is not clear to me why it is 6 and nothing in the spec > says it will not change. It's both hardcoded and enumerated. KVM's hardcoded value is specifically the maximum value expected for TDX-Module modules supporting the so called "1.0" spec. It's certainly possible a spec change could bump the maximum, but KVM will refuse to use a module with higher maximums until Linux/KVM is updated to play nice with the new module. Having hardcoded maximum allows for simpler and more efficient code, as loops and arrays can be statically defined instead of having to pass around the enumerated values. And we'd want sanity checking anyways, e.g. if the TDX-module pulled a stupid and reported that it needs 4000 TDCX pages. This approach gives KVM documented values to sanity check, e.g. instead of arbitrary magic numbers. The downside of this approach is that KVM will need to be updated to play nice with a new module if any of these maximums are raised. But, IMO that's acceptable because I can't imagine a scenario where anyone would want to load a TDX module without first testing the daylights out of the specific kernel+TDX combination, especially a TDX-module that by definition includes new features. > > >> +#define TDX1_MAX_NR_CMRS 32 > > >> +#define TDX1_MAX_NR_TDMRS 64 > > >> +#define TDX1_MAX_NR_RSVD_AREAS 16 > > >> +#define TDX1_PAMT_ENTRY_SIZE 16 > > >> +#define TDX1_EXTENDMR_CHUNKSIZE 256 > > > > > > I believe all of the defined variables above need to be enumerated > > > with TDH.SYS.INFO. And they are, though I believe the code for doing the actual SEAMCALL wasn't posted in this series. The output is sanity checked by tdx_hardware_enable(): + tdx_caps.tdcs_nr_pages = tdsysinfo->tdcs_base_size / PAGE_SIZE; + if (tdx_caps.tdcs_nr_pages != TDX1_NR_TDCX_PAGES) + return -EIO; + + tdx_caps.tdvpx_nr_pages = tdsysinfo->tdvps_base_size / PAGE_SIZE - 1; + if (tdx_caps.tdvpx_nr_pages != TDX1_NR_TDVPX_PAGES) + return -EIO; + + tdx_caps.attrs_fixed0 = tdsysinfo->attributes_fixed0; + tdx_caps.attrs_fixed1 = tdsysinfo->attributes_fixed1; + tdx_caps.xfam_fixed0 = tdsysinfo->xfam_fixed0; + tdx_caps.xfam_fixed1 = tdsysinfo->xfam_fixed1; + + tdx_caps.nr_cpuid_configs = tdsysinfo->num_cpuid_config; + if (tdx_caps.nr_cpuid_configs > TDX1_MAX_NR_CPUID_CONFIGS) + return -EIO; +