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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 18B3EC3815B for ; Mon, 20 Apr 2020 14:05:54 +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 DCEC820722 for ; Mon, 20 Apr 2020 14:05:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCEC820722 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 1jQX3L-0003tl-3A; Mon, 20 Apr 2020 14:05:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jQX3J-0003tg-2h for xen-devel@lists.xenproject.org; Mon, 20 Apr 2020 14:05:37 +0000 X-Inumbo-ID: 01724392-8310-11ea-9e09-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01724392-8310-11ea-9e09-bc764e2007e4; Mon, 20 Apr 2020 14:05:36 +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 638B9AEA2; Mon, 20 Apr 2020 14:05:34 +0000 (UTC) Subject: Re: [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit PV support To: Andrew Cooper References: <20200417155004.16806-1-andrew.cooper3@citrix.com> <20200417155004.16806-2-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <5dc9dbd9-fbeb-46ef-4d4e-7916c3219bb3@suse.com> Date: Mon, 20 Apr 2020 16:05:33 +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: <20200417155004.16806-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 17.04.2020 17:50, Andrew Cooper wrote: > This is the start of some performance and security-hardening improvements, > based on the fact that 32bit PV guests are few and far between these days. > > Ring1 is full or architectural corner cases, such as counting as supervisor ... full of ... > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1694,7 +1694,17 @@ The following resources are available: > CDP, one COS will corespond two CBMs other than one with CAT, due to the > sum of CBMs is fixed, that means actual `cos_max` in use will automatically > reduce to half when CDP is enabled. > - > + > +### pv > + = List of [ 32= ] > + > + Applicability: x86 > + > +Controls for aspects of PV guest support. > + > +* The `32` boolean controls whether 32bit PV guests can be created. It > + defaults to `true`, and is ignored when `CONFIG_PV32` is compiled out. Rather than ignoring in the way you do, how about ... > --- a/xen/arch/x86/pv/domain.c > +++ b/xen/arch/x86/pv/domain.c > @@ -16,6 +16,39 @@ > #include > #include > > +#ifdef CONFIG_PV32 > +int8_t __read_mostly opt_pv32 = -1; > +#endif > + > +static int parse_pv(const char *s) > +{ > + const char *ss; > + int val, rc = 0; > + > + do { > + ss = strchr(s, ','); > + if ( !ss ) > + ss = strchr(s, '\0'); > + > + if ( (val = parse_boolean("32", s, ss)) >= 0 ) > + { > +#ifdef CONFIG_PV32 > + opt_pv32 = val; > +#else > + printk(XENLOG_INFO > + "CONFIG_PV32 disabled - ignoring 'pv=32' setting\n"); > +#endif > + } ... moving the #ifdef ahead of the if(), and the #endif here (may want converting to "else if" with a placeholder if(0) for this purpose), with the separate printk() dropped? I'm in particular concerned that we may gain a large number of such printk()s over time, if we added them in such cases. See parse_iommu_param() for how I'd prefer things to look like in the long run. Jan