[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/6] x86/cpu-policy: Drop build time cross-checks of featureset sizes


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 8 May 2023 08:47:29 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hchJlrRfsacPsTKLPlIoSqERfo9BbLE4ltWKo+IyKQ8=; b=aSXOvM5spfhFIAM09Ja0glGPauzTxC8hi/F9Buual1tDZDIztCbKSGK87lqTyVo+NxlqgpeQ0f0mS2jhgeASWPk/TVcotsiJ5W+iudKtpOqEZeopIVKyHFni2cpOun6Kts/2WZXllTlSSnRsqf+JnpjQgDLVtbNLHoO1MVwxjKvdeYW+820wVRhFx80AGc4eZWGBIf1QtQt/EiSmsA2xTVdM47cO5uJxCOcrPJYB7BX9kQInTXoRUPFn/5vg+OwVe9z/DOeQAnTjtMMmzCa/P8SNq6je+P3psGoO4aSlH95kqIqQxJQUrXg38G15E6FrbdAPhEx2X4rLsvf0zVBuaQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cjdfPY20SLys+79uzy3JuzD8RelYB5oOUxnczN5aaF+OC5Zjp4V1L+inrdUIYfrUT10AaczZ9PKuePmBF9PbwHOFCUuu0fh8NPOHSLO9GWPWm+OwiTGZceP/qhEbHZqhfFLFBKd2bYw6n+PlqgONYsb2xpG7MaGLlUY1VB8+GcyghbMKfMgF878cuAaqJ6PY81K0VaGMEGyPLpgUNBq05c8OO4M55851OeF/9y/zjVNRFEz0bkwFAUdrbsRtXRgemrBDYypjRV8G6QSJuG/ZnpJU8LA91HRL1QwnUt65ZAKQPVcbVWvdr+0wzRrYSgwDUNIRN01KMJpi0AMfKUIT0w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 08 May 2023 06:48:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.05.2023 21:39, Andrew Cooper wrote:
> These BUILD_BUG_ON()s exist to cover the curious absence of a diagnostic for
> code which looks like:
> 
>   uint32_t foo[1] = { 1, 2, 3 };
> 
> However, GCC 12 at least does now warn for this:
> 
>   foo.c:1:24: error: excess elements in array initializer [-Werror]
>     884 | uint32_t foo[1] = { 1, 2, 3 };
>         |                        ^
>   foo.c:1:24: note: (near initialization for 'foo')

I'm pretty sure all gcc versions we support diagnose such cases. In turn
the arrays in question don't have explicit dimensions at their
definition sites, and hence they derive their dimensions from their
initializers. So the build-time-checks are about the arrays in fact
obtaining the right dimensions, i.e. the initializers being suitable.

With the core part of the reasoning not being applicable, I'm afraid I
can't even say "okay with an adjusted description".

Jan

> and has found other array length issues which we want to fix.  Drop the cross
> check now tools can spot the problem case directly.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> ---
>  xen/arch/x86/cpu-policy.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
> index ef6a2d0d180a..44c88debf958 100644
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -883,12 +883,6 @@ void __init init_dom0_cpuid_policy(struct domain *d)
>  
>  static void __init __maybe_unused build_assertions(void)
>  {
> -    BUILD_BUG_ON(ARRAY_SIZE(known_features) != FSCAPINTS);
> -    BUILD_BUG_ON(ARRAY_SIZE(pv_max_featuremask) != FSCAPINTS);
> -    BUILD_BUG_ON(ARRAY_SIZE(hvm_shadow_max_featuremask) != FSCAPINTS);
> -    BUILD_BUG_ON(ARRAY_SIZE(hvm_hap_max_featuremask) != FSCAPINTS);
> -    BUILD_BUG_ON(ARRAY_SIZE(deep_features) != FSCAPINTS);
> -
>      /* Find some more clever allocation scheme if this trips. */
>      BUILD_BUG_ON(sizeof(struct cpu_policy) > PAGE_SIZE);
>  




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.