2016-04-05 13:20+0200, Igor Mammedov: > On Mon, 4 Apr 2016 22:34:08 +0200 > Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: >> 2016-04-04 21:14+0200, Igor Mammedov: >> >> (And firmware doesn't implement x2APIC, and other minor >> >> problems ...) >> > Firmware probably doesn't need more than 1 VCPU, maybe we can >> > get rid of if it enumerating VCPUs via broadcast AP wakeup >> > since it no longer builds ACPI tables anymore. >> > >> > It should save some boot time due to removing timeout for waiting >> > APs wakeup. >> >> Rudimentary x2APIC support is needed, because the OS should get >> control with all LAPICs in x2APIC mode when any APIC ID is over 255. >> We could code that in QEMU to save some time, but I am reluctant to >> move the whole MP initialization before >255 is proven as working. :) > As you said it's up to OS to get control of all LAPICs, i.e. wake them > up. I probably miss something but how would firmware be involved in > this? The spec says that putting all LAPICs into x2APIC mode is firmware's job (10.12.8.1 Consistency of APIC IDs and CPUID, but we can do it in QEMU). An OS can expect that all LAPICs will be in x2APIC mode, which causes a problem if the firmware didn't switch to x2APIC, because non-broadcast INIT/SIPI to to high APIC IDs would fail. I'm lost now, are we talking about optimizing seabios' smp_setup()? (I think smp_setup touches APs because of SDM, Dec 2015, 8.4.3 MP Initialization Protocol Algorithm for MP Systems, items 6 and 7.) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
