Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1260810pxj; Fri, 21 May 2021 09:55:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyclyj6oV9W0rF4dCFHI/zsY4dM2TIERKGhzqrxA7ZAzq2AgHwk7Ris4Thbm1iwxg7/jMda X-Received: by 2002:a05:6402:416:: with SMTP id q22mr12310958edv.204.1621616155929; Fri, 21 May 2021 09:55:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621616155; cv=none; d=google.com; s=arc-20160816; b=YmHHWAbNK0InKpVnSqXvdG5Ds/Y5928JL1X9/f6Ocm90X7vaEQGLyVt2gd2ElAPp85 q6HMUId9KYUbnn7RqT1ons18UBgX19qFa/U97E75SJKhgsUTrAYuHD5RTA9xYqwiDM/i vpqz+ScbCVtxzYe7WxLJJSv/nIVu2w9o88h5mMaYohalSqrDthDeVyxOhqdOlWure244 YmoZm16DgFXfgR+tyLkJeFUZb9WG/SxCGsmfNzIDhqW99jxo/TxgYjgBt1/CCIkfCNRh BBEzu2fYylfJVviIihP1jjp3cAaf5LRlQm+6qXGOZl3tB4zf9nqO6sjXRsoVa4IDl4Zv 6s3g== 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=DKaftpjv7H83Jh/uRtII0tq3p9ECwTnXtKKu/Rh05PI=; b=l18R1spPJN4gCCnJwVLB8Eg0lt0ZZhIVCr3Iu+K/DXgHmsjfcZ8Gla4aEe57yeQox1 ZF36gYkzlyzw9N66diUafYOtjFrVXwbtK/bQQrC+0J2XD4XlZo1M9qsm78YOEylzVh9U otoTrN1j6RNeh9fcwFs+ItHpuWdDlu+9UUiXDOrT6R/vzP5qPshG5ihsSa5/GbCiglPT xdToEALLx2jEJ+ULDLPVoxciCk1ePhPMKbzAFYszYa39xMqHjGjQDbqShDy6v9Fj8mde TD9tCNO71W+qhM9zIF7fqqKmTmhhQQZRY2tcFDBVWc/8CDQwdrc3aV6ZUDybU8X/8q+O 1ejA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vz5G03Jq; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rs6si6054407ejb.266.2021.05.21.09.55.32; Fri, 21 May 2021 09:55:55 -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=@google.com header.s=20161025 header.b=vz5G03Jq; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237415AbhETTex (ORCPT + 99 others); Thu, 20 May 2021 15:34:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234189AbhETTex (ORCPT ); Thu, 20 May 2021 15:34:53 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1AF86C061574 for ; Thu, 20 May 2021 12:33:28 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id ep16-20020a17090ae650b029015d00f578a8so5847817pjb.2 for ; Thu, 20 May 2021 12:33:28 -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=DKaftpjv7H83Jh/uRtII0tq3p9ECwTnXtKKu/Rh05PI=; b=vz5G03Jq3T+zYlANXUXDryLqsRfrAPGj9W2taWRFdoAqGpZb9TiwgFz6Ogsh6l69kb JdPBtixQGnCKuAjOaWr3RFRc37fQZXsY9umWWFIr9btcsZ2H6JvT/yUdwCaPzbadtkk7 N1Ozq3SS/8ad81RVsvUvY0I0pwjvMahpz/+P0lx9rO4DvRc3eowOqndgZyTWno9I4ZXO qm1nnrbXkFkzbI6LM68ZxsFc2B4C8MgChsg4h8eU7hTrpYYrvE6c/6Wo2z76zNKgTbBO E/Y/DGO0KUByry4G6Cp9DKF7jIUQHysttBXkHfXRkQWEOqyqWRD14EtyaLwftyOhAUfL FSPA== 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=DKaftpjv7H83Jh/uRtII0tq3p9ECwTnXtKKu/Rh05PI=; b=mjbqTcFZFAD27BfvIybHzEzHbVRAtPDO910GOCzTPI8YHFMmYU8seOoOksLpEgkFHv nnzE2PykkMk4wdOfdUi4RWm5KTsL28TWf5blCVkUjAC/b3vVJLmDZh8ZDjrRRtjG/IDp vIbz5bQy193sRBoTm3Xelr4m+jwK4sxZkvQAjNhd/32jg8v/g4j10yU/192czLCUGVuD kBe6Jhq0dJibNvisBDmrN2JX697Lv8kEX4hYrP+bHULvyqmLnhlw3oHAuU6QeLOdsVZp y397K/sawPxLyo3cq85LAhtaKF/yfra6rxXiklV9t+plJmyBPGcYnkxekRO7yJD3ODiP DzqQ== X-Gm-Message-State: AOAM5310POLd5MdyrbwRQZ4ulzncMYvMzaRJX4IalJBx3eLSsvXkcfnK 38CH+TFfYYpWQp55f4dcsG10bw== X-Received: by 2002:a17:90a:7486:: with SMTP id p6mr6949639pjk.216.1621539207345; Thu, 20 May 2021 12:33:27 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id b17sm2565876pgb.71.2021.05.20.12.33.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 12:33:26 -0700 (PDT) Date: Thu, 20 May 2021 19:33:22 +0000 From: Sean Christopherson To: "Kuppuswamy, Sathyanarayanan" Cc: Dave Hansen , Peter Zijlstra , Andy Lutomirski , Dan Williams , Tony Luck , Andi Kleen , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Raj Ashok , linux-kernel@vger.kernel.org Subject: Re: [RFC v2 27/32] x86/tdx: Exclude Shared bit from __PHYSICAL_MASK Message-ID: References: <87b31425b79df3cc44d2bdc6a79d6aa36c42d116.1619458733.git.sathyanarayanan.kuppuswamy@linux.intel.com> <3ae38a0b-0676-1543-7015-39a589b2807a@intel.com> <0df80c0f-e0da-e86e-0ab8-abc58f0da559@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0df80c0f-e0da-e86e-0ab8-abc58f0da559@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 20, 2021, Kuppuswamy, Sathyanarayanan wrote: > Hi Dave, > > On 5/19/21 9:14 AM, Dave Hansen wrote: > > On 4/26/21 11:01 AM, Kuppuswamy Sathyanarayanan wrote: > > > From: "Kirill A. Shutemov" > > > > > > tdx_shared_mask() returns the mask that has to be set in a page > > > table entry to make page shared with VMM. > > > > Here's a rewrite: > > > > Just like MKTME, TDX reassigns bits of the physical address for > > metadata. MKTME used several bits for an encryption KeyID. TDX uses a > > single bit in guests to communicate whether a physical page should be > > protected by TDX as private memory (bit set to 0) or unprotected and > > shared with the VMM (bit set to 1). > > > > Add a helper, tdg_shared_mask() (bad name please fix it) to generate the > > Initially we have used tdx_* prefix for the guest code. But when the code from > host side got merged together, we came across many name conflicts. Whatever the conflicts are, they are by no means an unsolvable problem. I am more than happy to end up with slightly verbose names in KVM if that's what it takes to avoid "tdg". > So to avoid such issues in future, we were asked not to use the "tdx_" prefix > and our alternative choice was "tdg_". Who asked you not to use tdx_? More specifically, did that feedback come from a maintainer (or anyone on-list), or was it an Intel-internal decision? > Also, IMO, "tdg" prefix is more meaningful for guest code (Trusted Domain Guest) > compared to "tdx" (Trusted Domain eXtensions). I know that it gets confusing > when grepping for TDX related changes. But since these functions are only used > inside arch/x86 it should not be too confusing. > > Even if rename is requested, IMO, it is easier to do it in one patch over > making changes in all the patches. So if it is required, we can do it later > once these initial patches were merged. Hell no, we are not merging known bad crud that requires useless churn to get things right.