linux-kernel - Re: [PATCH v2] arm64: gic: increase the number of IRQ descriptors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 04 Jan 2023 09:14:40 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Shanker Donthineni <sdonthineni@...dia.com>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        James Morse <james.morse@....com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] arm64: gic: increase the number of IRQ descriptors

On Wed, 04 Jan 2023 02:37:38 +0000,
Shanker Donthineni <sdonthineni@...dia.com> wrote:
> 
> The default value of NR_IRQS is not sufficient to support GICv4.1
> features and ~56K LPIs. This parameter would be too small for certain
> server platforms where it has many IO devices and is capable of
> direct injection of vSGI and vLPI features.
> 
> Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors
> are allowed. The vCPU creation fails after reaching count ~400 with
> kvm-arm.vgic_v4_enable=1.
> 
> This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144
> vSGIs (16K vPEs x 16).
> 
> Signed-off-by: Shanker Donthineni <sdonthineni@...dia.com>
> ---
> Changes since v1:
>  -create from v6.2-rc1 and edit commit text
> 
>  arch/arm64/include/asm/irq.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
> index fac08e18bcd5..3fffc0b8b704 100644
> --- a/arch/arm64/include/asm/irq.h
> +++ b/arch/arm64/include/asm/irq.h
> @@ -4,6 +4,10 @@
>  
>  #ifndef __ASSEMBLER__
>  
> +#if defined(CONFIG_ARM_GIC_V3_ITS)
> +#define  NR_IRQS  (1 << 19)
> +#endif
> +
>  #include <asm-generic/irq.h>
>  
>  struct pt_regs;

Sorry, but I don't think this is an acceptable change. This is a large
overhead that affects *everyone*, and that will eventually be too
small anyway with larger systems and larger interrupt spaces.

A better way to address this would be to move to a more dynamic
allocation, converting the irqdesc rb-tree into an xarray, getting rid
of the bitmaps (the allocation bitmap and the resend one), and track
everything in the xarray.

This would scale, avoid allocations, and benefit all architectures.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.