On 06/20/16 13:15, Igor Mammedov wrote:
On Mon, 20 Jun 2016 10:45:37 +0200
Gerd Hoffmann <kraxel(a)redhat.com> wrote:
On Mo, 2016-05-16 at 21:00 -0400, Kevin
On Wed, May 11, 2016 at 12:03:37PM +0200, Igor
* merge handle_x2apic() into apic_id_init()
* move out max-cpus check out of mptable_setup()
* factor out CPU counting/apic ID detection in separate
* return back accidentially deleted debug message with APIC ID
* drop unused code in smp_setup()
According to SDM, if CPUs have APIC ID more than 254
firmware should pass control to OS in x2APIC mode.
This series adds x2APIC bootstrap initialization.
QEMU side of x2APIC support:
Thanks Igor. The first 3 patches look good to me. I'll commit to
SeaBIOS once the corresponding QEMU support is accepted.
Ping. What is the status of this in qemu? qemu 2.7 soft freeze is
coming, and it is about time to plan the seabios update (1.9.3
I need to dust RFC off and respin as Paolo wanted to sync APIC ID
other way than in RFC and also on list there is v2 ACPI refactoring
that x2APIC enablement depends on.
wrt OVMF does suggested here fw_Cfg interface look ok to you?
I checked your v2 series quickly, with more attention to "etc/boot-cpus"
and patch #3.
I also re-read your argument in
Reasons, I've skipped CPUID[0xb]:edx is not
because it's currently not
supported but rather:
1st: we already have 'etc/max-cpus' which is 'max possible APIC ID +
1', so reuse it.
2nd: beside complicating(making it longer, timewise) AP bootstrap,
detection at runtime wouldn't work in case of CPU hotplug as it
won't detect x2APIC CPUs if they are not yet present. real HW
might work around this issue just hardcodding what APIC mode it
wants as possible APIC IDs are known in advance for a particular
I think it should be okay.
For OVMF I have no idea yet how we're going to accommodate this.
Minimally it will depend on fixing
in UefiCpuPkg. But, the
"etc/boot-cpus" interface looks sane to me.