linux-kernel - Re: [PATCH v2] RISC-V: Increase range and default value of NR

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 for Android: free password hash cracker in your pocket

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

Message-ID: <mhng-9cbb2a46-8bcb-4bfe-b927-0ed469dbd3a6@palmer-mbp2014>
Date:   Thu, 31 Mar 2022 12:42:34 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     apatel@...tanamicro.com
CC:     Paul Walmsley <paul.walmsley@...ive.com>,
        Arnd Bergmann <arnd@...db.de>, atishp@...shpatra.org,
        Alistair Francis <Alistair.Francis@....com>,
        anup@...infault.org, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org, apatel@...tanamicro.com
Subject:     Re: [PATCH v2] RISC-V: Increase range and default value of NR_CPUS

On Sat, 19 Mar 2022 05:12:06 PDT (-0700), apatel@...tanamicro.com wrote:
> Currently, the range and default value of NR_CPUS is too restrictive
> for high-end RISC-V systems with large number of HARTs. The latest
> QEMU virt machine supports upto 512 CPUs so the current NR_CPUS is
> restrictive for QEMU as well. Other major architectures (such as
> ARM64, x86_64, MIPS, etc) have a much higher range and default
> value of NR_CPUS.
>
> This patch increases NR_CPUS range to 2-512 and default value to
> XLEN (i.e. 32 for RV32 and 64 for RV64).
>
> Signed-off-by: Anup Patel <apatel@...tanamicro.com>
> ---
> Changes since v1:
>  - Updated NR_CPUS range to 2-512 which reflects maximum number of
>    CPUs supported by QEMU virt machine.
> ---
>  arch/riscv/Kconfig | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 5adcbd9b5e88..423ac17f598c 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -274,10 +274,11 @@ config SMP
>  	  If you don't know what to do here, say N.
>
>  config NR_CPUS
> -	int "Maximum number of CPUs (2-32)"
> -	range 2 32
> +	int "Maximum number of CPUs (2-512)"
> +	range 2 512
>  	depends on SMP
> -	default "8"
> +	default "32" if 32BIT
> +	default "64" if 64BIT
>
>  config HOTPLUG_CPU
>  	bool "Support for hot-pluggable CPUs"

I'm getting all sorts of boot issues with more than 32 CPUs, even on the 
latest QEMU master.  I'm not opposed to increasing the CPU count in 
theory, but if we're going to have a setting that goes up to a huge 
number it needs to at least boot.  I've got 64 host threads, so it 
shouldn't just be a scheduling thing.

If there was some hardware that actually boots on these I'd be happy to 
take it, but given that it's just QEMU I'd prefer to sort out the bugs 
first.  It's probably just latent bugs somewhere, but allowing users to 
turn on configs we know don't work just seems like the wrong way to go.