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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 9BB81C43460 for ; Mon, 10 May 2021 15:52:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F661615FF for ; Mon, 10 May 2021 15:52:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231812AbhEJPxh (ORCPT ); Mon, 10 May 2021 11:53:37 -0400 Received: from mga17.intel.com ([192.55.52.151]:18037 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231558AbhEJPxY (ORCPT ); Mon, 10 May 2021 11:53:24 -0400 IronPort-SDR: y9dIWG64qIKryxleJ682CFKXp/duFvsUvFivkoFNeh3t+eiUfg6uc61zFbgiJYwQ13WDASoBGb dN81BmVT0dng== X-IronPort-AV: E=McAfee;i="6200,9189,9980"; a="179488770" X-IronPort-AV: E=Sophos;i="5.82,287,1613462400"; d="scan'208";a="179488770" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2021 08:52:16 -0700 IronPort-SDR: 27OxFMx8kBBjIQtItvuM1QSdQTrvYwqDTKVkFjoUUwrMw2+wwZexGL1NWnkSc2ae8sV7nWchi9 h1oU74SsLuiw== X-IronPort-AV: E=Sophos;i="5.82,287,1613462400"; d="scan'208";a="433865599" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.32.217]) ([10.209.32.217]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2021 08:52:16 -0700 Subject: Re: [RFC v2 01/32] x86/paravirt: Introduce CONFIG_PARAVIRT_XL To: Juergen Gross , Borislav Petkov , Kuppuswamy Sathyanarayanan Cc: Peter Zijlstra , Andy Lutomirski , Dave Hansen , Dan Williams , Tony Luck , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Raj Ashok , Sean Christopherson , linux-kernel@vger.kernel.org References: <4f8c9559dd04d8e8485c419c5ebc9471613f7928.1619458733.git.sathyanarayanan.kuppuswamy@linux.intel.com> From: Andi Kleen Message-ID: Date: Mon, 10 May 2021 08:52:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org \ >>> CONFIG_PARAVIRT_XL will be used by TDX that needs couple of paravirt >>> calls that were hidden under CONFIG_PARAVIRT_XXL, but the rest of the >>> config would be a bloat for TDX. >> >> Used how? Why is it bloat for TDX? > > Is there any major downside to move the halt related pvops functions > from CONFIG_PARAVIRT_XXL to CONFIG_PARAVIRT? I think the main motivation is to get rid of all the page table related hooks for modern configurations. These are the bulk of the annotations and  cause bloat and worse code. Shadow page tables are really obscure these days and very few people still need them and it's totally reasonable to build even widely used distribution kernels without them. On contrast most of the other hooks are comparatively few and also on comparatively slow paths, so don't really matter too much. I think it would be ok to have a CONFIG_PARAVIRT that does not have page table support, and a separate config option for those (that could be eventually deprecated). But that would break existing .configs for those shadow stack users, that's why I think Kirill did it the other way around. -Andi