xen/arm: fix sparse cpu_possible_map calculation on SMP boot

Currently, during ARM Xen's SMP initialization, if there is
a Device Tree error (such as an invalid 'enable-method'),
cpu_possible_map can end up being sparse.

The issue here is that nr_cpu_ids is calculated in a way that
doesn't properly account for the maximum CPU ID when the map is
sparse, causing a mismatch. For example, if cpu_possible_map is
0xff0f, nr_cpu_ids becomes 12, but the actual maximum CPU ID
is 15. Xen's common code is built on the assumption that
'CPU ID < nr_cpu_ids', so this mismatch can break things.

To fix this, modify dt_smp_init_cpus() so that if the
arch_cpu_init() call fails, we don't consume the CPU ID slot.

Fixes: 4557c22928 ("xen: arm: rewrite start of day page table and cpu bring up")
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
(cherry picked from commit ccde3773c1)

xen/arch/arm/smpboot.c

@@ -238,7 +238,9 @@ static void __init dt_smp_init_cpus(void)
         if ( (rc = arch_cpu_init(i, cpu)) < 0 )
         {
             printk("cpu%d init failed (hwid %"PRIregister"): %d\n", i, hwid, rc);
-            tmp_map[i] = MPIDR_INVALID;
+
+            if ( i != 0 )
+                cpuidx--;
         }
         else
             tmp_map[i] = hwid;
@@ -251,10 +253,9 @@ static void __init dt_smp_init_cpus(void)
         return;
     }
 
-    for ( i = 0; i < cpuidx; i++ )
+    /* Skip CPU 0 as it was already initialized in smp_prepare_boot_cpu(). */
+    for ( i = 1; i < cpuidx; i++ )
     {
-        if ( tmp_map[i] == MPIDR_INVALID )
-            continue;
         cpumask_set_cpu(i, &cpu_possible_map);
         cpu_logical_map(i) = tmp_map[i];
     }