soc/intel/common/block/acpi: Skip generatic LAPIC entries for non-exi…

…sting CPUs

MADT LAPIC entries were generated for all CPUs in range 0 to
CONFIG_MAX_CPUS regardless of their existence. This caused the
cpu->path.apic.core_type field to have a different value than specified
in cpu_perf_eff_type enum and extra efficient cores being added to the
list with an unusuallly high APIC ID dereferenced from NULL pointer.
For systems which obtain LAPICs/CPUs topology from MADT, like ESXI, it
resulted in finding more CPUs than available in the system (exactly one
more core in case of ESXi, because other entries had the same ACPI ID
and were ignored as duplicates). SMP initialization failed in such case
with timeout on waking a non-existent CPU core.

TEST=Boot ESXi in headless mode on VP6670.

Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>

src/soc/intel/common/block/acpi/cpu_hybrid.c

@@ -54,6 +54,9 @@ static void acpi_set_hybrid_cpu_apicid_order(void *unused)
 	uint32_t i, j = 0;
 
 	for (i = 0; i < ARRAY_SIZE(cpu_apic_info.apic_ids); i++) {
+		if (!cpu_infos[i].cpu)
+			continue;
+
 		if (cpu_infos[i].cpu->path.apic.core_type == CPU_TYPE_PERF)
 			cpu_apic_info.apic_ids[perf_core_cnt++] =
 				cpu_infos[i].cpu->path.apic.apic_id;