On Tue, 18 Oct 2016 08:39:05 -0200 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Tue, Oct 18, 2016 at 11:12:04AM +0200, Igor Mammedov wrote: > > On Mon, 17 Oct 2016 19:44:52 -0200 > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > On Thu, Oct 13, 2016 at 11:52:39AM +0200, Igor Mammedov wrote: > > > [...] > > > > @@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, > > > > MachineState *machine, > > > > /* The current AML generator can cover the APIC ID range [0..255], > > > > * inclusive, for VCPU hotplug. */ > > > > QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256); > > > > - g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT); > > > > + if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) { > > > > + error_report("max_cpus is too large. APIC ID of last CPU is > > > > %u", > > > > + pcms->apic_id_limit - 1); > > > > + exit(1); > > > > + } > > > > > > Moving the check here seems to make sense, but: > > > > > > > > > > > /* create PCI0.PRES device and its _CRS to reserve CPU hotplug > > > > MMIO */ > > > > dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE)); > > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > > > index 93ff49c..f1c1013 100644 > > > > --- a/hw/i386/pc.c > > > > +++ b/hw/i386/pc.c > > > > @@ -778,7 +778,6 @@ static FWCfgState *bochs_bios_init(AddressSpace > > > > *as, PCMachineState *pcms) > > > > > > [Added more context below to show the code around the change] > > > > > > > numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + > > > > nb_numa_nodes); > > > > numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes); > > > > for (i = 0; i < max_cpus; i++) { > > > > unsigned int apic_id = x86_cpu_apic_id_from_index(i); > > > > - assert(apic_id < pcms->apic_id_limit); > > > > > > If you really needed to remove this assert, that means you can > > > write beyond the end of numa_fw_fg[] below. Are you sure you need > > > to remove it? > > > > > > > j = numa_get_node_for_cpu(i); > > > > if (j < nb_numa_nodes) { > > > > numa_fw_cfg[apic_id + 1] = cpu_to_le64(j); > > > > > > ^^^^^^^^^^^ here > > > > > > > } > > Another more radical way to deal with legacy FW_CFG_NUMA > > could be to remove it altogether if machine has x2APIC cpus. > > It'd be possible to do due to BIOS using QEMU provided > > BIOS tables and not using/calling code for built in/legacy > > ACPI tables. > > > > Could do it as patch on top if that's sounds ok. > > I don't mind either way. Initializing the fields even if they are > not going to be used seems harmless, but if you believe skipping > it would make things simpler, go ahead. Keying of >255 cpus is a chance to drop legacy FW_CFG_NUMA which isn't used by modern QEMU/SeaBIOS. We can't do that for < 255 as it would break migration/BIOS where it is already present. I'll look at it some more from SeaBIOS perspective if it's feasible/useful. > In this case, what would happen if x2apic CPUs are available but > the BIOS is too old? Old BIOS is unfixable is there are more than 255, most often old BIOS would hang in smp_setup() waiting cmos_smp_count CPUs to wakeup or crash later if smp_scan() lucky and wins the race. Or BIOS could fail earlier/later during buffer overflow/allocation when initializing legacy ACPI tables/pir/mp_table if etc/max-cpus is big enough. Corresponding SeaBIOS series is mentioned in cover letter. This series or dropping FW_CFG_NUMA should not affect (existing) VMs with less that 255 CPUs though.