linux-kernel - Re: [PATCH v9 21/30] KVM: arm64: Initialise hyp_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: <86cy3lmt94.wl-maz@kernel.org>
Date: Wed, 07 Jan 2026 13:45:11 +0000
From: Marc Zyngier <maz@...nel.org>
To: Vincent Donnefort <vdonnefort@...gle.com>
Cc: rostedt@...dmis.org,
	mhiramat@...nel.org,
	mathieu.desnoyers@...icios.com,
	linux-trace-kernel@...r.kernel.org,
	oliver.upton@...ux.dev,
	joey.gouly@....com,
	suzuki.poulose@....com,
	yuzenghui@...wei.com,
	kvmarm@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	jstultz@...gle.com,
	qperret@...gle.com,
	will@...nel.org,
	aneesh.kumar@...nel.org,
	kernel-team@...roid.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 21/30] KVM: arm64: Initialise hyp_nr_cpus for nVHE hyp

On Tue, 02 Dec 2025 09:36:14 +0000,
Vincent Donnefort <vdonnefort@...gle.com> wrote:
> 
> Knowing the number of CPUs is necessary for determining the boundaries
> of per-cpu variables, which will be used for upcoming hypervisor
> tracing. hyp_nr_cpus which stores this value, is only initialised for
> the pKVM hypervisor. Make it accessible for the nVHE hypervisor as well.
> 
> With the kernel now responsible for initialising hyp_nr_cpus, the
> nr_cpus parameter is no longer needed in __pkvm_init.
> 
> Signed-off-by: Vincent Donnefort <vdonnefort@...gle.com>
> 
> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> index e6be1f5d0967..b169d85458f9 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -128,8 +128,7 @@ void __noreturn __hyp_do_panic(struct kvm_cpu_context *host_ctxt, u64 spsr,
>  #ifdef __KVM_NVHE_HYPERVISOR__
>  void __pkvm_init_switch_pgd(phys_addr_t pgd, unsigned long sp,
>  		void (*fn)(void));
> -int __pkvm_init(phys_addr_t phys, unsigned long size, unsigned long nr_cpus,
> -		unsigned long *per_cpu_base, u32 hyp_va_bits);
> +int __pkvm_init(phys_addr_t phys, unsigned long size, unsigned long *per_cpu_base, u32 hyp_va_bits);
>  void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
>  #endif
>  
> @@ -146,5 +145,6 @@ extern u64 kvm_nvhe_sym(id_aa64smfr0_el1_sys_val);
>  extern unsigned long kvm_nvhe_sym(__icache_flags);
>  extern unsigned int kvm_nvhe_sym(kvm_arm_vmid_bits);
>  extern unsigned int kvm_nvhe_sym(kvm_host_sve_max_vl);
> +extern unsigned long kvm_nvhe_sym(hyp_nr_cpus);
>  
>  #endif /* __ARM64_KVM_HYP_H__ */
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 052bf0d4d0b0..7ba427f9608c 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -35,6 +35,7 @@
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_asm.h>
>  #include <asm/kvm_emulate.h>
> +#include <asm/kvm_hyp.h>
>  #include <asm/kvm_mmu.h>
>  #include <asm/kvm_nested.h>
>  #include <asm/kvm_pkvm.h>
> @@ -2396,7 +2397,7 @@ static int __init do_pkvm_init(u32 hyp_va_bits)
>  	preempt_disable();
>  	cpu_hyp_init_context();
>  	ret = kvm_call_hyp_nvhe(__pkvm_init, hyp_mem_base, hyp_mem_size,
> -				num_possible_cpus(), kern_hyp_va(per_cpu_base),
> +				kern_hyp_va(per_cpu_base),
>  				hyp_va_bits);
>  	cpu_hyp_init_features();
>  
> @@ -2605,6 +2606,8 @@ static int __init init_hyp_mode(void)
>  		kvm_nvhe_sym(kvm_arm_hyp_percpu_base)[cpu] = (unsigned long)page_addr;
>  	}
>  
> +	kvm_nvhe_sym(hyp_nr_cpus) = num_possible_cpus();

Is num_possible_cpus() always the correct thing to do? Given that pKVM
doesn't support late onlining, this really should be the number of
online CPUs.

Probably not a big deal, but worth thinking about it.

Thanks,

	M.

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