SeaBIOS November 2013

seabios@seabios.org

18 participants
43 discussions

Re: [SeaBIOS] Booted IVB with FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 bootloader -> Win8.1
by Marc Jones 11 Nov '13

11 Nov '13

Hi Zoran, Yes, that is our expectation. We should be landing these patches soon... Thanks for the report. Regards, Marc On Mon, Nov 11, 2013 at 8:35 AM, Stojsavljevic, Zoran <zoran.stojsavljevic(a)intel.com> wrote: > Hello Patrick, Marc, > > > > Half an hour ago I was able to make it on IVB Emerald Lake 2 CRB, using > sequence: FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 > bootloader -> Win8.1! > > > > I used the real, a week old SeaBIOS image from git repo: SeaBIOS version > 1.7.3-88-gf08e847. > > > > In other words, this does mean that Marc’s Jones patches will work after new > Coreboot release. Please, note that just initial testing is done to this > load! > > > > Best Regards, > > Zoran > > _______ > > Most of The Time you should be “intel inside” to be capable to think “out of > the box”. > > > > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Booted IVB with FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 bootloader -> Win8.1
by Stojsavljevic, Zoran 11 Nov '13

11 Nov '13

Hello Patrick, Marc, Half an hour ago I was able to make it on IVB Emerald Lake 2 CRB, using sequence: FSP -> Coreboot -> SeaBIOS (1.7.3 with CSM mode set) -> Win 8.1 bootloader -> Win8.1! I used the real, a week old SeaBIOS image from git repo: SeaBIOS version 1.7.3-88-gf08e847. In other words, this does mean that Marc’s Jones patches will work after new Coreboot release. Please, note that just initial testing is done to this load! Best Regards, Zoran _______ Most of The Time you should be “intel inside” to be capable to think “out of the box”. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [SeaBIOS] [Qemu-devel][RFC PATCH] i386: Add _PXM method to ACPI CPU objects
by Michael S. Tsirkin 11 Nov '13

11 Nov '13

On Thu, Nov 07, 2013 at 01:41:59PM +0100, Vasilis Liaskovitis wrote: > This patch adds a _PXM method to ACPI CPU objects for the pc machine. The _PXM > value is derived from the passed in guest info, same way as CPU SRAT entries. > > The motivation for this patch is a CPU hot-unplug/hot-plug bug observed when > using a 3.11 linux guest kernel on a multi-NUMA node qemu/kvm VM. The linux > guest kernel parses the SRAT CPU entries at boot time and stores them in the > array __apicid_to_node. When a CPU is hot-removed, the linux guest kernel > resets the removed CPU's __apicid_to_node entry to NO_NUMA_NODE (kernel commit > c4c60524). When the removed cpu is hot-added again, the linux kernel looks up > the hot-added cpu object's _PXM method instead of somehow re-discovering the > SRAT entry info. With current qemu/seabios, the _PXM method is not found, and > the CPU is thus hot-plugged in the default NUMA node 0. (The problem does not > show up on initial hotplug of a cpu; the PXM method is still not found in this > case, but the kernel still has the correct proximity value from the CPU's SRAT > entry stored in __apicid_to_node) > > ACPI spec mentions that the _PXM method is the correct way to determine > proximity information at hot-add time. Where does it say this? I found this: If the Local APIC ID / Local SAPIC ID / Local x2APIC ID of a dynamically added processor is not present in the System Resource Affinity Table (SRAT), a _PXM object must exist for the processor’s device or one of its ancestors in the ACPI Namespace. Does this mean that linux is buggy, and should be fixed up to look up the apic ID in SRAT? > So far, qemu/seabios do not provide this > method for CPUs. So regardless of kernel behaviour, it is a good idea to add > this _PXM method. Since ACPI table generation has recently been moved from > seabios to qemu, we do this in qemu. > > Note that the above hot-remove/hot-add scenario has been tested on an older > qemu + non-upstreamed patches for cpu hot-removal support, and not on qemu > master (since cpu-del support is still not on master). The only testing done > with qemu/seabios master and this patch, are successful boots of multi-node > linux and windows8 guests. > > For the initial discussion on seabios and linux-acpi lists see > http://www.spinics.net/lists/linux-acpi/msg47058.html > > Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> > Reviewed-by: Thilo Fromm <t-lo(a)thilo-fromm.de> Even if this is a linux bug, I have no issue with working around it in qemu. But I think proper testing needs to be done with rebased upport for cpu-del. > --- > hw/i386/acpi-build.c | 2 ++ > hw/i386/ssdt-proc.dsl | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index 6cfa044..9373f5e 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -603,6 +603,7 @@ static inline char acpi_get_hex(uint32_t val) > #define ACPI_PROC_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2) > #define ACPI_PROC_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4) > #define ACPI_PROC_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start) > +#define ACPI_PROC_OFFSET_CPUPXM (*ssdt_proc_pxm - *ssdt_proc_start) > #define ACPI_PROC_SIZEOF (*ssdt_proc_end - *ssdt_proc_start) > #define ACPI_PROC_AML (ssdp_proc_aml + *ssdt_proc_start) > > @@ -724,6 +725,7 @@ build_ssdt(GArray *table_data, GArray *linker, > proc[ACPI_PROC_OFFSET_CPUHEX+1] = acpi_get_hex(i); > proc[ACPI_PROC_OFFSET_CPUID1] = i; > proc[ACPI_PROC_OFFSET_CPUID2] = i; > + proc[ACPI_PROC_OFFSET_CPUPXM] = guest_info->node_cpu[i]; > } > > /* build this code: > diff --git a/hw/i386/ssdt-proc.dsl b/hw/i386/ssdt-proc.dsl > index 8229bfd..7eef8b2 100644 > --- a/hw/i386/ssdt-proc.dsl > +++ b/hw/i386/ssdt-proc.dsl > @@ -47,6 +47,8 @@ DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC", "BXSSDT", 0x1) > * also updating the C code. > */ > Name(_HID, "ACPI0007") > + ACPI_EXTRACT_NAME_BYTE_CONST ssdt_proc_pxm > + Name(_PXM, 0xAA) The ACPI spec says this should be a DWORD value: Return Value: An Integer (DWORD) containing a proximity domain identifier. > External(CPMA, MethodObj) > External(CPST, MethodObj) > External(CPEJ, MethodObj) > -- > 1.7.10.4

3 4

[Qemu-devel][RFC PATCH] i386: Add _PXM method to ACPI CPU objects
by Vasilis Liaskovitis 07 Nov '13

07 Nov '13

This patch adds a _PXM method to ACPI CPU objects for the pc machine. The _PXM value is derived from the passed in guest info, same way as CPU SRAT entries. The motivation for this patch is a CPU hot-unplug/hot-plug bug observed when using a 3.11 linux guest kernel on a multi-NUMA node qemu/kvm VM. The linux guest kernel parses the SRAT CPU entries at boot time and stores them in the array __apicid_to_node. When a CPU is hot-removed, the linux guest kernel resets the removed CPU's __apicid_to_node entry to NO_NUMA_NODE (kernel commit c4c60524). When the removed cpu is hot-added again, the linux kernel looks up the hot-added cpu object's _PXM method instead of somehow re-discovering the SRAT entry info. With current qemu/seabios, the _PXM method is not found, and the CPU is thus hot-plugged in the default NUMA node 0. (The problem does not show up on initial hotplug of a cpu; the PXM method is still not found in this case, but the kernel still has the correct proximity value from the CPU's SRAT entry stored in __apicid_to_node) ACPI spec mentions that the _PXM method is the correct way to determine proximity information at hot-add time. So far, qemu/seabios do not provide this method for CPUs. So regardless of kernel behaviour, it is a good idea to add this _PXM method. Since ACPI table generation has recently been moved from seabios to qemu, we do this in qemu. Note that the above hot-remove/hot-add scenario has been tested on an older qemu + non-upstreamed patches for cpu hot-removal support, and not on qemu master (since cpu-del support is still not on master). The only testing done with qemu/seabios master and this patch, are successful boots of multi-node linux and windows8 guests. For the initial discussion on seabios and linux-acpi lists see http://www.spinics.net/lists/linux-acpi/msg47058.html Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> Reviewed-by: Thilo Fromm <t-lo(a)thilo-fromm.de> --- hw/i386/acpi-build.c | 2 ++ hw/i386/ssdt-proc.dsl | 2 ++ 2 files changed, 4 insertions(+) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index 6cfa044..9373f5e 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -603,6 +603,7 @@ static inline char acpi_get_hex(uint32_t val) #define ACPI_PROC_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2) #define ACPI_PROC_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4) #define ACPI_PROC_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start) +#define ACPI_PROC_OFFSET_CPUPXM (*ssdt_proc_pxm - *ssdt_proc_start) #define ACPI_PROC_SIZEOF (*ssdt_proc_end - *ssdt_proc_start) #define ACPI_PROC_AML (ssdp_proc_aml + *ssdt_proc_start) @@ -724,6 +725,7 @@ build_ssdt(GArray *table_data, GArray *linker, proc[ACPI_PROC_OFFSET_CPUHEX+1] = acpi_get_hex(i); proc[ACPI_PROC_OFFSET_CPUID1] = i; proc[ACPI_PROC_OFFSET_CPUID2] = i; + proc[ACPI_PROC_OFFSET_CPUPXM] = guest_info->node_cpu[i]; } /* build this code: diff --git a/hw/i386/ssdt-proc.dsl b/hw/i386/ssdt-proc.dsl index 8229bfd..7eef8b2 100644 --- a/hw/i386/ssdt-proc.dsl +++ b/hw/i386/ssdt-proc.dsl @@ -47,6 +47,8 @@ DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC", "BXSSDT", 0x1) * also updating the C code. */ Name(_HID, "ACPI0007") + ACPI_EXTRACT_NAME_BYTE_CONST ssdt_proc_pxm + Name(_PXM, 0xAA) External(CPMA, MethodObj) External(CPST, MethodObj) External(CPEJ, MethodObj) -- 1.7.10.4

1 0

Re: [SeaBIOS] [RFC PATCH] Add _PXM to CPU objects for NUMA hot-plug
by Kevin O'Connor 07 Nov '13

07 Nov '13

On Mon, Nov 04, 2013 at 11:51:49AM +0100, Vasilis Liaskovitis wrote: > Any comment on this? > > On Fri, Oct 25, 2013 at 11:32:10AM +0200, Vasilis Liaskovitis wrote: > > This patch adds a _PXM object to seabios CPU objects. The _PXM value is derived > > from CPU SRAT entries, so build_ssdt needs to be called after build_srat for > > this to work. I think ACPI changes should be done at QEMU. Going forward, QEMU will pass the tables into SeaBIOS. -Kevin

2 1

Re: [SeaBIOS] [RFC PATCH] Add _PXM to CPU objects for NUMA hot-plug
by Toshi Kani 06 Nov '13

06 Nov '13

On Mon, 2013-11-04 at 11:51 +0100, Vasilis Liaskovitis wrote: > Any comment on this? > > On Fri, Oct 25, 2013 at 11:32:10AM +0200, Vasilis Liaskovitis wrote: > > This patch adds a _PXM object to seabios CPU objects. The _PXM value is derived > > from CPU SRAT entries, so build_ssdt needs to be called after build_srat for > > this to work. > > > > The motivation for this patch is a CPU hot-unplug/hot-plug bug observed when > > using seabios and a 3.11 linux guest kernel on a multi-NUMA node qemu/kvm VM. > > The linux guest kernel parses the SRAT CPU entries at boot time and stores them > > in the array __apicid_to_node. When a CPU is hot-removed, the linux guest kernel > > resets the removed CPU's __apicid_to_node entry to NO_NUMA_NODE (kernel commit > > c4c60524). When the removed cpu is hot-added again, the linux kernel looks up > > the hot-added cpu object's _PXM value instead of somehow re-using the SRAT > > entry info (acpi_map_cpu2node calls acpi_get_node which calls acpi_get_pxm). If > > the _PXM value is not found, the CPU is assumed to be on node 0, and it is > > hot-plugged in the wrong NUMA node. > > > > Which is the preferred OSPM way of looking up a CPU's proximity info at hotplug > > time? Is it the CPU object's _PXM value, or the already-parsed CPU SRAT entry? > > Or maybe both ways are valid? SRAT describes proximity values at boot-time. During hotplug, the kernel is supposed to obtain the current proximity value from _PXM method. > > This issue may require a kernel fix alternatively or additionally to the seabios > > fix: The kernel can save the originally parsed SRAT entry info somewhere before > > it resets it at hot-remove time, and use that info on hot-plug time if the _PXM > > value is missing for the hot-plugged CPU BIOS object. This way CPU hot-plug > > works well against a BIOS with no CPU _PXM info. To support CPU hotplug, seabios needs to implement _PXM to CPU or its parent device object when the system has multiple nodes. Thanks, -Toshi

3 4

[PATCH v7 0/3] seabios: load acpi tables from qemu
by Michael S. Tsirkin 06 Nov '13

06 Nov '13

This is the seabios code that adds support for loading acpi tables from QEMU. Changes from v6: - submission was botched, it didn't compile fix up patch biostables: support looking up RSDP no changes to other patches Changes from v5: - address Kevin's comments: move code to find rsdp to biostables.c scan for RSDP at 0x10 intervals Changes from v4: - address Kevin's comments: move loader to src/fw/ simplify some code drop some unused code chunks load from ROM even if !ACPI rename option to make it non ACPI specific Changes from v3: - updated to latest bits - add option to disable loading from QEMU Changes from v2: - addressed comments from Kevin: fixed coding style, minimized changes to existing code Changes from v1: - simplified linker interfaces along the lines suggested by Kevin - fixed lots of bugs Michael S. Tsirkin (3): biostables: support looking up RSDP romfile_loader: utility to patch in-memory ROM files acpi: load and link tables through romfile loader Makefile | 2 +- src/fw/romfile_loader.h | 72 ++++++++++++++++++++ src/util.h | 1 + src/fw/acpi.c | 21 ++++++ src/fw/biostables.c | 41 +++++++++-- src/fw/romfile_loader.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++++ src/Kconfig | 11 +++ 7 files changed, 317 insertions(+), 8 deletions(-) create mode 100644 src/fw/romfile_loader.h create mode 100644 src/fw/romfile_loader.c -- MST

2 7

[PATCH for 1.7] pc: disable pci-info
by Igor Mammedov 05 Nov '13

05 Nov '13

The BIOS that we ship in 1.7 does not use pci info from host and so far isn't going to use it. Taking in account problems it caused see 9604f70fdf and to avoid future incompatibility issues, it's safest to disable that interface by default for all machine types including 1.7 as it was never exposed/used by guest. And properly remove/cleanup it during 1.8 development cycle. Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> --- hw/i386/pc_piix.c | 3 ++- hw/i386/pc_q35.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index c6042c7..4a4d969 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -58,7 +58,8 @@ static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 }; static const int ide_irq[MAX_IDE_BUS] = { 14, 15 }; static bool has_pvpanic; -static bool has_pci_info = true; +/* TODO: remove unused "etc/pci-info" */ +static bool has_pci_info; /* PC hardware initialisation */ static void pc_init1(QEMUMachineInitArgs *args, diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c index ca84e1c..8e5c1ae 100644 --- a/hw/i386/pc_q35.c +++ b/hw/i386/pc_q35.c @@ -48,7 +48,8 @@ #define MAX_SATA_PORTS 6 static bool has_pvpanic; -static bool has_pci_info = true; +/* TODO: remove unused "etc/pci-info" */ +static bool has_pci_info; /* PC hardware initialisation */ static void pc_q35_init(QEMUMachineInitArgs *args) -- 1.7.1

4 5

Re: [SeaBIOS] XHCI USB 3.0 boot device support?
by Gerd Hoffmann 04 Nov '13

04 Nov '13

On Fr, 2013-11-01 at 15:26 -0700, Prop 395 wrote: > Is there currently any activity to get XHCI going in SeaBIOS? What > needs to be implemented to get it working? If someone can give me > some pointers, I will do what I can to help. Supported in master, no release with the xhci driver yet though. cheers, Gerd

2 1

[PATCH v3 0/3] usb: add xhci support
by Gerd Hoffmann 04 Nov '13

04 Nov '13

Hi, Next version of the xhci support patch series. Changed xhci device list to use standard hlist macros. Delete devices from list in disconnect() callback, so we should not have inactive/freed devices in the list. cheers, Gerd Gerd Hoffmann (3): uas: add (temporary) superspeed stopgap usb: add usb_update_pipe() usb: add xhci support Makefile | 2 +- src/Kconfig | 6 + src/pci_ids.h | 1 + src/usb-uas.c | 4 + src/usb-xhci.c | 1124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/usb-xhci.h | 144 ++++++++ src/usb.c | 35 +- src/usb.h | 17 +- 8 files changed, 1320 insertions(+), 13 deletions(-) create mode 100644 src/usb-xhci.c create mode 100644 src/usb-xhci.h -- 1.8.3.1

4 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS November 2013