On Tue, 14 May 2019, Julien Grall wrote:
> There are no reason to consider the HW CPU ID will be 0 when the
> processor is part of a uniprocessor system. At best, this will result to
> conflicting output as the rest of Xen use the value directly read from
> MPIDR.
>
> So remove the zeroing and logic to check if the CPU is part of a
> uniprocessor system.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes in v2:
> - Add Andrii's reviewed-by
> ---
> xen/arch/arm/arm32/head.S | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> index 9f40face98..d42a13556c 100644
> --- a/xen/arch/arm/arm32/head.S
> +++ b/xen/arch/arm/arm32/head.S
> @@ -124,16 +124,8 @@ GLOBAL(init_secondary)
> mov r12, #1 /* r12 := is_secondary_cpu */
>
> common_start:
> - mov r7, #0 /* r7 := CPU ID. Initialy zero until we
> - * find that multiprocessor extensions are
> - * present and the system is SMP */
> mrc CP32(r1, MPIDR)
> - tst r1, #MPIDR_SMP /* Multiprocessor extension supported? */
> - beq 1f
> - tst r1, #MPIDR_UP /* Uniprocessor system? */
> - bne 1f
> bic r7, r1, #(~MPIDR_HWID_MASK) /* Mask out flags to get CPU ID */
> -1:
>
> /* Non-boot CPUs wait here until __cpu_up is ready for them */
> teq r12, #0
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel