On 03/13/2012 10:51 AM, Gleb Natapov wrote:
On Tue, Mar 13, 2012 at 10:37:54AM +0100, Igor Mammedov wrote:
On 03/13/2012 01:09 AM, Kevin O'Connor wrote:
On Sat, Mar 10, 2012 at 12:47:28PM +0100, Igor Mammedov wrote:
Initial count of active cpus is communicated to bios from qemu via CMOS_BIOS_SMP_COUNT io port. However if cpus are hotplugged after boot and then guest is rebooted without taking down qemu then bios might be stuck at smp_probe
[...]
--- a/src/smp.c +++ b/src/smp.c @@ -17,6 +17,9 @@
#define APIC_ENABLED 0x0100
+#define ACPI_CPU_STATUS_MAP 0xaf00 +#define ACPI_CPU_STATUS_MAP_SZ 32
- struct { u32 ecx, eax, edx; } smp_mtrr[32] VAR16VISIBLE; u32 smp_mtrr_count VAR16VISIBLE;
@@ -115,6 +118,26 @@ smp_probe(void) msleep(10); } else { u8 cmos_smp_count = inb_cmos(CMOS_BIOS_SMP_COUNT);
dprintf(1, "Powered-on with %d cpu(s)\n", cmos_smp_count + 1);
if (qemu_cfg_have_acpi_cpus_map()) {
[...]
Please don't clutter up smp.c with this. The code should look something like:
int total_cpus = getCPUcount(); while (readl(&CountCPUs)< total_cpus) yield();
The getCPUcount() can be buried in paravirt.c, acpi.c, or where ever it makes sense.
Thanks Kevin, I'll amend and repost patch-set taking in account your suggestions.
BTW, why do we have to call qemu_cfg_have_acpi_cpus_map? Can't this just be inferred if the data at inb(0xaf00) is all zeros?
We can't rely on the fact that unused port returns all zeros. Actually on real HW I think it return all ones.
What if qemu doesn't have 0xaf00 (like current upstream)? cfg_have_acpi_cpus_map is just a flag that allows to detect if qemu provides 0xaf00. This way it would be possible for seabios to work with old and new versions of qemu without breaking anything.
If QEMU will update cmos cpu count on cpu (un)plug we will not have to introduce new PV interface to telll SeaBIOS about 0xaf00.
But we will have to introduce it anyway in future for correct building of mp/acpi/smbios tables. So why not do it now and be ready later for patches to mp/acpi/smbios tables.
-- Gleb.