[SeaBIOS] [PATCH 1/2] fw/acpi: Build MADT the way commodity BIOSes do

[Igor Mammedov]

On Tue, 31 Jan 2017 17:32:55 +0000
"Sironi, Filippo" <sironi at amazon.de> wrote:

> > On 30 Jan 2017, at 04:39, Igor Mammedov <imammedo at redhat.com> wrote:
> > 
> > On Fri, 27 Jan 2017 15:57:19 +0100
> > Laszlo Ersek <lersek at redhat.com> wrote:
> >   
> >> On 01/27/17 15:27, Kevin O'Connor wrote:  
> >>> On Fri, Jan 27, 2017 at 02:18:39AM +0100, Filippo Sironi wrote:  
> >>>> When running Linux on an Intel machine with a commodity BIOS, CPUs are
> >>>> numbered starting from 0 and the first half refers to the first logical
> >>>> CPU on each core while the second half refers to the second logical CPU
> >>>> on each core.
> >>>> As an example, on machine with 2 sockets, 4 cores per socket, and 2
> >>>> logical CPUs per core, CPUs would be numbered:
> >>>> 
> >>>> *  0  1  2  3 - first logical CPU on each core of socket 0
> >>>> *  4  5  6  7 - first logical CPU on each core of socket 1
> >>>> *  8  9 10 11 - second logical CPU on each core of socket 0
> >>>> * 12 13 14 15 - second logical CPU on each core of socket 1  
> > 
> > ACPI spec says
> > "
> > platform firmware should list the first logical processor of each of
> > the individual multi-threaded processors in the MADT before listing
> > any of the second logical processors.
> > "
> > 
> > socket order is not mandated there and for example I have a system
> > where apic id's re listed as following:
> >  0x0  - first logical CPU on each core 0 of socket 0
> >  0x10 - first logical CPU on each core 0 of socket 1
> >  0x2  - first logical CPU on each core 1 of socket 0 
> >  0x12 - first logical CPU on each core 1 of socket 1
> > ...
> > 
> > the main point is that first threads are listed first
> > (which socket/core order is not important except of boot CPU)
> > and only after that goes list of secondary threads.
> > 
> > QEMU currently doesn't conform to above guideline as MADT is 1.0 revision
> > doesn't have such requirement.
> > However patches are welcome to make it adhering to the later ACPI specs.
> > See build_madt() function to see how it's generated now.
> > 
> > Also does patch fix any particular issue/problem or just making MADT
> > conform to spec?  
> 
> SeaBIOS changes aside, when running a Linux VM with QEMU/KVM with the following command line:
> 
> qemu-system-x86_64 -machine q35,accel=kvm,iommu=on -cpu host -smp threads=2,cores=2,sockets=1 -m 2048 -device e1000,netdev=local,romfile= -netdev user,id=local,hostfwd=tcp::7000-:22 -serial stdio -vnc :1 -k en-us -drive file=ubuntu-14.04.qcow2,index=0,media=disk
> 
> /proc/cpuinfo reports the following:
> 
> # cat /proc/cpuinfo 
> processor	: 0
> ...
> physical id	: 0
> siblings	: 4
> core id		: 0
> cpu cores	: 2
> apicid		: 0
> initial apicid	: 0
> ...
> 
> processor	: 1
> ...
> physical id	: 0
> siblings	: 4
> core id		: 0
> cpu cores	: 2
> apicid		: 1
> initial apicid	: 1
> ...
> 
> processor	: 2
> ...
> physical id	: 0
> siblings	: 4
> core id		: 1
> cpu cores	: 2
> apicid		: 2
> initial apicid	: 2
> ...
> 
> processor	: 3
> ...
> physical id	: 0
> siblings	: 4
> core id		: 1
> cpu cores	: 2
> apicid		: 3
> initial apicid	: 3
> 
> where the HT siblings couples are CPU0 and CPU1, CPU2 and CPU3 while according to the ACPI specification they should be CPU0 and CPU2, CPU1 and CPU3.
IMHO: CPU numbering in kernel is not ACPI spec regulated and I'd say
it's arbitrary. For x86, cpus are numbered in order they are initialized,
so if for example there is hotpluggable CPUs and they were hotplugged in reverse
order (ex. the last socket first) then kernel would continue sequentially
numbering them in the order they are hotplugged.

> So, my understanding is that even QEMU needs to be fixed and I can work to provide a patch.
> However, as I was mentioning before, I'm also interesting in updating SeaBIOS since one can use it without using QEMU.
most of smp initialization in SeaBIOS is called in QEMU only mode
so ordering in legacy MADT is the least of issues if
one would like to run SeaBIOS on baremetal.

> 
> Filippo
> 
> 
> Amazon Development Center Germany GmbH
> Berlin - Dresden - Aachen
> main office: Krausenstr. 38, 10117 Berlin
> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> Ust-ID: DE289237879
> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
>