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?
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.
-Kevin
--
-----
Igor
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
