June 2013 - SeaBIOS - mail.coreboot.org

[PULL 0/2] update seabios to release 1.7.2.2
by Gerd Hoffmann June 17, 2013

June 17, 2013

Hi, This pull updates seabios to the 1.7.2.2 release tagged yesterday, bringing some fixes which unfortunaly missed the qemu 1.5 boat. please pull, Gerd The following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29: Remove Sun4c, Sun4d and a few CPUs (2013-05-26 11:37:58 +0000) are available in the git repository at: git://git.kraxel.org/qemu seabios-1.7.2.2 for you to fetch changes up to 6683d7bc2759e9da8b5c4907a9de85d500933ffb: update seabios to release 1.7.2.2 (2013-05-28 12:19:02 +0200) ---------------------------------------------------------------- Gerd Hoffmann (2): Revert "roms: switch oldnoconfig to olddefconfig" update seabios to release 1.7.2.2 pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/configure-seabios.sh | 2 +- roms/seabios | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-)

2 3

Re: [SeaBIOS] [Qemu-devel] solaris x86 in qemu? [bisected]
by Michael Tokarev June 17, 2013

June 17, 2013

13.06.2013 11:51, Michael Tokarev wrote: > Hello. > > In order to verify some build issues on solaris, I tried to install > sol10 x86 in a kvm vm. But unfortunately it does not work: after the > grub prompt and choosing "Solaris 10 x86" boot entry, the kernel > gets loaded (there's a row of dots displayed during that), next, > the following message gets displayed: > > SunOS Release 5.10 Version Generic_147148-26 64-bit > Copyright (c) 1983, 2013 Oracle and/or its affiliates. All rights reserved. > > and the guest stays there for a long time, spinning up 100% of its CPU, > and nothing more happens. > > The same happens when run with or without kvm (ie, tcg and kvm behaves > the same way). > > When run in kvm, kvm_stats shows just a few exits (about 600/sec) and > nothing more than that. > > I think that supporting solaris as _guest_ OS is an important goal > for qemu/kvm (as opposed to _host_). I tried to bisect this. It turns out that solaris x86 does not boot in qemu/kvm for quite long time already, namely, starting from this commit: commit 6b034aa138716a515c88f7894940d5d0aff2f3ed Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Tue Apr 17 10:51:41 2012 +0200 seabios: update to 1.7.0 Update roms/seabios and pc-bios/bios.bin to the 1.7.0 release. Most noticable new feature is virtio-scsi support. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> So I went on and tried to bisect seabios (previous version in qemu was 1.6.3.2, and it worked). So seabios bisection with qemu-1.1 points to this commit: commit 9d3d7cb4b163d3fbcba64a01c4fa42eb6bc53128 Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Wed Sep 21 21:19:51 2011 -0400 Move code from PCI hotplug DSDT macros to methods. Simplify the hotplug code by moving the bulk of the logic out of the macros and into static method definitions. This also reduces the ACPI DSDT code size. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> Now, I don't really understand what's going on there... ;) And since this is DSDT, using seabios 1.6 with recent qemu does not solve the problem, since DSDT is now external/separate. Thanks, /mjt

4 9

Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
by Paolo Bonzini June 16, 2013

June 16, 2013

Il 10/06/2013 21:03, Anthony Liguori ha scritto: >>> I'm not really convinced that >>> QEMU<->firmware is a GPL boundary because of how tightly the two are >>> linked. >> >> Where has 'linked' in terms of the GPL ever been anything other than >> actual executable linking? > > I should not have even brought this up as it's not worth debating. If > you're curious, http://www.gnu.org/licenses/gpl-faq.html#MereAggregation With the usual IANAL care, I think QOM would be much much more of a legal grey area that passing ACPI tables. If you pass ACPI tables, the ACPI tables are clearly part of QEMU, and are almost as clearly "just data" for the BIOS. But if you use QOM, you may start wondering if "the semantics of the communication are intimate enough, exchanging complex internal data structures". Probably not, as it is a generic interface and there could be in principle other consumers than the firmware, but still complex enough that raising the issue is not moot. Paolo

2 2

master is broken
by Gerd Hoffmann June 14, 2013

June 14, 2013

Hi, Switching the list handling broke pci initialization. Commit aab42152881dc62b37f1833e79cbdb3dfa51603b seems to be the culprit. --- log-446defb 2013-06-13 11:53:38.444435298 +0200 +++ log-aab4215 2013-06-13 11:53:11.137304303 +0200 @@ -1,8 +1,8 @@ -Start bios (version rel-1.7.2-132-g446defb-20130613_115336-rincewind.home.kraxel.org) +Start bios (version rel-1.7.2-133-gaab4215-20130613_115307-rincewind.home.kraxel.org) No Xen hypervisor found. Running on KVM Ram Size=0x40000000 (0x0000000000000000 high) -Relocating init from 0x000e0e18 to 0x3ffdfc00 (size 66356) +Relocating init from 0x000e0d68 to 0x3ffdfb60 (size 66524) Found QEMU fw_cfg CPU Mhz=2797 === PCI bus & bridge init === @@ -13,10 +13,8 @@ Found 6 PCI devices (max PCI bus is 00) PCI: check devices === PCI new allocation pass #2 === PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] -PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] -PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] -PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] -PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] +PCI: map device bdf=00:02.0 bar 6, addr febef000, size 00010000 [mem] +PCI: map device bdf=00:00.0 bar 1566990182, addr fc000000, size c366fcfaf4fbc366 [S<FF>] PCI: init bdf=00:00.0 id=8086:1237 PCI: init bdf=00:01.0 id=8086:7000 PIIX3/PIIX4 init: elcr=00 0c @@ -35,7 +33,7 @@ Scan for VGA option rom [ more stuff snipped ] cheers, Gerd

2 3

[PATCH] make qemu_cfg_init depend on QEMU_HARDWARE instead of QEMU
by Gerd Hoffmann June 14, 2013

June 14, 2013

Gets qemu features like direct kernel boot and boot ordering going when seabios runs on coreboot. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/paravirt.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/paravirt.c b/src/paravirt.c index d87a5e1..ae6e2a2 100644 --- a/src/paravirt.c +++ b/src/paravirt.c @@ -303,7 +303,7 @@ struct QemuCfgFile { void qemu_cfg_init(void) { - if (!CONFIG_QEMU) + if (!CONFIG_QEMU_HARDWARE || !runningOnQEMU()) return; // Detect fw_cfg interface. @@ -315,8 +315,10 @@ void qemu_cfg_init(void) return; dprintf(1, "Found QEMU fw_cfg\n"); - // Populate romfiles for legacy fw_cfg entries - qemu_cfg_legacy(); + if (CONFIG_QEMU) { + // Populate romfiles for legacy fw_cfg entries + qemu_cfg_legacy(); + } // Load files found in the fw_cfg file directory u32 count; -- 1.7.9.7

2 2

Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
by Michael S. Tsirkin June 14, 2013

June 14, 2013

On Mon, Jun 10, 2013 at 08:03:46PM -0500, Anthony Liguori wrote: > >> It is not "supported" by QEMU. > > > > No, but I've always thought that QEMU was happy to have alternative > > firmware projects. > > We are and we're happy to accept patches to enable things even if its > proprietary. But that's all assuming we're improving hardware > emulation. > > What we're talking about here is doing something that's very un-hardware like. Two points 1. You never explained what you mean by un-hardware like. Currently bios is in a ROM device, and it has a template for ACPI tables together with it. This simply moves the tables to a separate ROM device (FW CFG), and generalizes the template using the linker interface. One ROM is hardware-like but two is un-hardware like? ACPI tables are static so it's likely lots of hardware has at least some of them pre-formatted in flash, then tweak some things like SRAT a bit. 2. There's no hardware-like alternative. A current alternative is exposing lots of PV interfaces to bios, bios builds up ACPI tables based on them. All of this code is in practice PC only, if we ever attempt to generalize we'll see how the interfaces are not a good match. They are still PV, poorly documented and it's very hard for bios not to make any assumptions about them. When it does, result is a very obscure breakage. Yes, building tables in bios means QEMU code is simpler but we double the amount of interfaces that we need to get right: QEMU-BIOS + BIOS-OS Yes it's "not QEMU code" but it's seen as a single package by users and it does not really matter - excellent hardware with lousy firmware is useless. -- MST

4 3

[PATCH RFC 0/3] qemu/acpi-build: cross migration fixes
by Michael S. Tsirkin June 13, 2013

June 13, 2013

This patchset, on top of my acpi branch, fixes the issues with cross-version migration: - Don't add fw cfg entries when running with -M 1.5 and older - Future proof against future ACPI table changes: create a ROM blob so the tables are migrated (together with BIOS) With these changes the ACPI generation patchset will become mergeable. I say *will* since it's only lightly tested, I intend to test properly and re-post the full patchset with acpi table geneation in QEMU ready for merge, next week. Posting for early flames/review. Michael S. Tsirkin (3): loader: support for unmapped ROM blobs acpi: add tables as ROM so they are migrated acpi-build: disable acpi generation for compat hw/core/loader.c | 32 +++++++++++++++++++++++++++++--- hw/i386/acpi-build.c | 19 +++++++++++++++++++ hw/i386/pc_piix.c | 12 ++++++++++-- hw/i386/pc_q35.c | 12 ++++++++++-- hw/lm32/lm32_hwsetup.h | 2 +- include/hw/i386/pc.h | 1 + include/hw/loader.h | 4 ++-- 7 files changed, 72 insertions(+), 10 deletions(-) -- MST

1 0

[PATCH] tweak coreboot qemu detection
by Gerd Hoffmann June 13, 2013

June 13, 2013

I have patches for coreboot in the queue adding q35 support there, which will change the mainboard names (adding the detected chipset). Make SeaBIOS check the mainboard name starts with "QEMU" instead of doing a full string match to handle this. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/coreboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/coreboot.c b/src/coreboot.c index 6d255ca..5078e9a 100644 --- a/src/coreboot.c +++ b/src/coreboot.c @@ -167,7 +167,7 @@ coreboot_preinit(void) CBvendor = &cbmb->strings[cbmb->vendor_idx]; CBpart = &cbmb->strings[cbmb->part_idx]; if (strcmp(CBvendor, "Emulation") == 0 && - strcmp(CBpart, "QEMU x86") == 0) { + memcmp(CBpart, "QEMU", 4) == 0) { PlatformRunningOn |= PF_QEMU; } dprintf(1, "Found mainboard %s %s\n", CBvendor, CBpart); -- 1.7.9.7

1 0

[PATCH] make qemu_cfg_init depend on QEMU_HARDWARE instead of QEMU
by Gerd Hoffmann June 13, 2013

June 13, 2013

Gets qemu features like direct kernel boot and boot ordering going when seabios runs on coreboot. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/paravirt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/paravirt.c b/src/paravirt.c index d87a5e1..5793724 100644 --- a/src/paravirt.c +++ b/src/paravirt.c @@ -303,7 +303,7 @@ struct QemuCfgFile { void qemu_cfg_init(void) { - if (!CONFIG_QEMU) + if (!CONFIG_QEMU_HARDWARE || !runningOnQEMU()) return; // Detect fw_cfg interface. -- 1.7.9.7

2 2

[PATCH] config: allow DEBUG_IO for !QEMU
by Gerd Hoffmann June 13, 2013

June 13, 2013

Make DEBUG_IO depend on QEMU_HARDWARE instead of QEMU, so it can be enabled for seabios builds running indirectly (coreboot, csm) on qemu. Add runtime check for PF_QEMU to debug port console to make sure we don't poke on random ports on physical hardware. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/Kconfig | 2 +- src/output.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index 3c80132..5882d11 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -425,7 +425,7 @@ menu "Debugging" Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8. config DEBUG_IO - depends on QEMU && DEBUG_LEVEL != 0 + depends on QEMU_HARDWARE && DEBUG_LEVEL != 0 bool "Special IO port debugging" default y help diff --git a/src/output.c b/src/output.c index 79c3ada..d548766 100644 --- a/src/output.c +++ b/src/output.c @@ -11,6 +11,7 @@ #include "bregs.h" // struct bregs #include "config.h" // CONFIG_* #include "biosvar.h" // GET_GLOBAL +#include "paravirt.h" // PlatformRunningOn struct putcinfo { void (*func)(struct putcinfo *info, char c); @@ -77,7 +78,7 @@ putc_debug(struct putcinfo *action, char c) { if (! CONFIG_DEBUG_LEVEL) return; - if (CONFIG_DEBUG_IO) + if (CONFIG_DEBUG_IO && runningOnQEMU()) // Send character to debug port. outb(c, GET_GLOBAL(DebugOutputPort)); if (c == '\n') -- 1.7.9.7

2 2