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

Re: [PATCH 1/2] xen/arm: Improve handling of nr_spis


  • To: Michal Orzel <michal.orzel@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 11 Mar 2025 09:30:52 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=L5MFWdEUnP9vj/jX5gTEQcm/wFdBf9rXhqZIObbaEfI=; b=mjboyu6gI6R4sufZOOm2Rm5NDk9I3LPWGOkKB3XSNgjX4Ngt3naK+1IGOH8SHxZDaTMbNlAzCCz72WeAmN2O4OK1Tt4oISA4HKpsyoU1fGyOghD2aTc+/R72vbuhHOnYT2jypKAXZG/RcwpXcQYIBpDucVDiog9QGxHrTI/y6LGU2UmUQCwiDKMjDW42muHBC3+lv7QW2PdeYifNM1kfQWJLsl0fX7SiAizvspqEqMBfq7qPqTSvCQSK+Ek8CfNQnmMgLyxSKQM319iPbWO0WscH7z259Hy9FX5s80n5EjurLy9L/hNiKrZGLXG4hCR4MwuHMURTBe/33QShn9MKIA==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=L5MFWdEUnP9vj/jX5gTEQcm/wFdBf9rXhqZIObbaEfI=; b=xKGUyJq8SjK28WA+ZRAd4rvFNlsyDFL0ynOAL5K77y+0fSVcI9Ov5MO7jpsw9MlTLFaQY6zJYpBLw1bFDz/Zvz4gKew3G5Y51pBYDWK3TzslbOq5461u64zJKzwELnD4Y0oZGZHs1+if9LVez+sYgKSD4tfzmOrcGKm6OMqRQAATKpOXnoq/UNJvFqZK9N/ny9l1r//WtBcONkecW9DxuDcoFnAC8MphEOK5nEs//WS+f6uxGOIbJGhY3dPJDtIsVLZ83/24KATSZm1R1eZCCHF0erD1aXNXrq8tfTJzcEstVRQB4a9Dn1BCocoNdsspOXdyq8rjKyrOmCCU8GxiFA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=uj2Rhl28WiqCu5ZfexaJ7BWCZHx81Ri9hZm0nTR4pWOG1Be74dPpozoC18a6FKLPzISwpf322fAN0t0CuE3mQsecx1jeSfgLxRktEBDqbn2IpjUPNgP5yhV5HDMAbKeYI6GFRtIRD0GVvgkWUJuevR2QVYWkwD9NWKtf6TeUS4HUDrwlTtjQ9K+VVak5B+wEU147ZyigPXACxhiI/TznUTxNRxTRloSHIGuXH/Xd9EB9h2ZHUZt91BK4a2yRqryhDw/Ew9z7s9PVMDwRlyeFHtcqPH4GFPD1kyEhbI7u3eLmPYslh9/y2IT3lFiYxzIiMDm07rivDlUtmi7kGKQZDA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ODVVaOlCeHVJKVAa1BC2VM7VRlgWYFb/i5ogSNyV5mIjKVothcLXw4OmhwmhYrwbUm5dDYQP+aGxbfm9uWJkzu+3kPTSkVbW/wh3L9fR9QZq+FhTm+HPWwbZwwr/HQYkoQVghj9JOQj3RIOthSpaFCb1DeQWhIewEs0++fXWqirvZi3znts6wVjc3dHabTI/gSUr7EAmHpbwe59VFJ/oJ2QuZ8kOo1Z6gjbjp0erSoBm56dcTJ4WkreZmnrc9eHKSWV/NArkc8l2OsyF40ePQgMuCYrKvb22a4qU/HapBYX1ArC4NvRmSgiip+iu2tJfDhycxCjw+zKECiD2FszKHA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 11 Mar 2025 09:31:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHbkmScFxwSwnbWbUmo6sX8GQY3CLNtq7oA
  • Thread-topic: [PATCH 1/2] xen/arm: Improve handling of nr_spis

Hi Michal,

> On 11 Mar 2025, at 10:04, Michal Orzel <michal.orzel@xxxxxxx> wrote:
> 
> At the moment, we print a warning about max number of IRQs supported by
> GIC bigger than vGIC only for hardware domain. This check is not hwdom
> special, and should be made common. Also, in case of user not specifying
> nr_spis for dom0less domUs, we should take into account max number of
> IRQs supported by vGIC if it's smaller than for GIC.
> 
> Introduce VGIC_MAX_IRQS macro and use it instead of hardcoded 992 value.
> Fix calculation of nr_spis for dom0less domUs and make the GIC/vGIC max
> IRQs comparison common.
> 
> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> ---
> xen/arch/arm/dom0less-build.c   | 2 +-
> xen/arch/arm/domain_build.c     | 9 ++-------
> xen/arch/arm/gic.c              | 3 +++
> xen/arch/arm/include/asm/vgic.h | 3 +++
> 4 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 31f31c38da3f..9a84fee94119 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -1018,7 +1018,7 @@ void __init create_domUs(void)
>         {
>             int vpl011_virq = GUEST_VPL011_SPI;
> 
> -            d_cfg.arch.nr_spis = gic_number_lines() - 32;
> +            d_cfg.arch.nr_spis = min(gic_number_lines(), VGIC_MAX_IRQS) - 32;

I would suggest to introduce a static inline gic_nr_spis in a gic header ...

> 
>             /*
>              * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7cc141ef75e9..b99c4e3a69bf 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2371,13 +2371,8 @@ void __init create_dom0(void)
> 
>     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
>     dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> -    /*
> -     * Xen vGIC supports a maximum of 992 interrupt lines.
> -     * 32 are substracted to cover local IRQs.
> -     */
> -    dom0_cfg.arch.nr_spis = min(gic_number_lines(), (unsigned int) 992) - 32;
> -    if ( gic_number_lines() > 992 )
> -        printk(XENLOG_WARNING "Maximum number of vGIC IRQs exceeded.\n");
> +    /* 32 are substracted to cover local IRQs */
> +    dom0_cfg.arch.nr_spis = min(gic_number_lines(), VGIC_MAX_IRQS) - 32;

and reuse it here to make sure the value used is always the same.

>     dom0_cfg.arch.tee_type = tee_get_type();
>     dom0_cfg.max_vcpus = dom0_max_vcpus();
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index acf61a4de373..e80fe0ca2421 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -251,6 +251,9 @@ void __init gic_init(void)
>         panic("Failed to initialize the GIC drivers\n");
>     /* Clear LR mask for cpu0 */
>     clear_cpu_lr_mask();
> +
> +    if ( gic_number_lines() > VGIC_MAX_IRQS )
> +        printk(XENLOG_WARNING "Maximum number of vGIC IRQs exceeded\n");

I am a bit unsure with this one.
If this is the case, it means any gicv2 or gicv3 init detected an impossible 
value and
any usage of gic_number_lines would be using an impossible value.

Shouldn't this somehow result in a panic as the gic detection was wrong ?
Do you think we can continue to work safely if this value is over VGIC_MAX_IRQS.
There are other places using gic_number_lines like in irq.c.

Cheers
Bertrand


> }
> 
> void send_SGI_mask(const cpumask_t *cpumask, enum gic_sgi sgi)
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h
> index e309dca1ad01..c549e5840bfa 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -329,6 +329,9 @@ extern void vgic_check_inflight_irqs_pending(struct vcpu 
> *v,
>  */
> #define vgic_num_irqs(d)        ((d)->arch.vgic.nr_spis + 32)
> 
> +/* Maximum number of IRQs supported by vGIC */
> +#define VGIC_MAX_IRQS 992U
> +
> /*
>  * Allocate a guest VIRQ
>  *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
> -- 
> 2.25.1
> 




 


Rackspace

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