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=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 ED5CAC3815B for ; Mon, 20 Apr 2020 15:47:48 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C1A8D206DD for ; Mon, 20 Apr 2020 15:47:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1A8D206DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jQYdj-0005Nm-RH; Mon, 20 Apr 2020 15:47:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jQYdh-0005Nh-T4 for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 15:47:17 +0000 X-Inumbo-ID: 35caad7e-831e-11ea-9073-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 35caad7e-831e-11ea-9073-12813bfff9fa; Mon, 20 Apr 2020 15:47:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 401E9ADA3; Mon, 20 Apr 2020 15:47:15 +0000 (UTC) Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds To: Andrew Cooper References: <20200417155004.16806-1-andrew.cooper3@citrix.com> <20200417155004.16806-4-andrew.cooper3@citrix.com> <3c8eee8d-c2ce-d262-4056-a5d2c9f843cb@suse.com> From: Jan Beulich Message-ID: Date: Mon, 20 Apr 2020 17:47:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 20.04.2020 16:39, Andrew Cooper wrote: > On 20/04/2020 15:12, Jan Beulich wrote: >> On 17.04.2020 17:50, Andrew Cooper wrote: >>> There is no need for the Compat GDT if there are no 32bit PV guests. This >>> saves 4k per online CPU >>> >>> Bloat-o-meter reports the following savings in Xen itself: >>> >>> add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605) >>> Function old new delta >>> cpu_smpboot_free 1249 1256 +7 >>> per_cpu__compat_gdt_l1e 8 - -8 >>> per_cpu__compat_gdt 8 - -8 >>> init_idt_traps 442 420 -22 >>> load_system_tables 414 364 -50 >>> trap_init 444 280 -164 >>> cpu_smpboot_callback 1255 991 -264 >>> boot_compat_gdt 4096 - -4096 >>> Total: Before=3062726, After=3058121, chg -0.15% >>> >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Jan Beulich >>> CC: Wei Liu >>> CC: Roger Pau Monné >>> >>> The increase in cpu_smpboot_free() appears to be a consequence of a totally >>> different layout of basic blocks. >>> --- >>> xen/arch/x86/cpu/common.c | 5 +++-- >>> xen/arch/x86/desc.c | 2 ++ >>> xen/arch/x86/smpboot.c | 5 ++++- >>> xen/arch/x86/traps.c | 10 +++++++--- >>> 4 files changed, 16 insertions(+), 6 deletions(-) >>> >>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c >>> index 1b33f1ed71..7b093cb421 100644 >>> --- a/xen/arch/x86/cpu/common.c >>> +++ b/xen/arch/x86/cpu/common.c >>> @@ -752,8 +752,9 @@ void load_system_tables(void) >>> >>> _set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss, >>> sizeof(*tss) - 1, SYS_DESC_tss_avail); >>> - _set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss, >>> - sizeof(*tss) - 1, SYS_DESC_tss_busy); >>> + if ( IS_ENABLED(CONFIG_PV32) ) >>> + _set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss, >>> + sizeof(*tss) - 1, SYS_DESC_tss_busy); >> Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then. > > Doing it like this specifically ensures that there is never a case where > things are half configured. But this way you set up something in the GDT that's never going to be used when "pv=no-32". Why leave a TSS accessible that we don't need? > I don't think it is wise to suggest that making opt_pv32 runtime > configurable might work. I didn't suggest (nor even consider) runtime changing of this setting. If we wanted, _that_ would be what might require using code as you have it right now (if we wanted to avoid setting this up at the time the setting gets flipped from false to true). Jan