[SeaBIOS] master is broken
Hi, Switching the list handling broke pci initialization. Commit aab42152881dc62b37f1833e79cbdb3dfa51603b seems to be the culprit. --- log-446defb 2013-06-13 11:53:38.35298 +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=0x4000 (0x 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 c000, size 0020 [io] -PCI: map device bdf=00:01.1 bar 4, addr c020, size 0010 [io] -PCI: map device bdf=00:02.0 bar 6, addr febe, size 0001 [mem] -PCI: map device bdf=00:02.0 bar 1, addr febf, size 1000 [mem] -PCI: map device bdf=00:02.0 bar 0, addr fc00, size 0200 [prefmem] +PCI: map device bdf=00:02.0 bar 6, addr febef000, size 0001 [mem] +PCI: map device bdf=00:00.0 bar 1566990182, addr fc00, size c366fcfaf4fbc366 [S] 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] master is broken
On Thu, Jun 13, 2013 at 11:59:15AM +0200, Gerd Hoffmann wrote: > Hi, > > Switching the list handling broke pci initialization. > Commit aab42152881dc62b37f1833e79cbdb3dfa51603b seems to be the culprit. Thanks. I reverted that patch while I take another look at it. Sorry about that. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH RFC 0/3] qemu/acpi-build: cross migration fixes
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] solaris x86 in qemu? [bisected]
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 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 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 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 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto: > 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. Also having a "bootstrap processor" was certainly not unheard of some decades ago. Right now we get all sort of SMM hacks instead of adding more processors, but it's certainly not un-hardware like. Maybe we should just have a bytecode interpreter and write the ACPI generator in that language. :) Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] solaris x86 in qemu? [bisected]
On Fri, Jun 14, 2013 at 12:32:22AM +0400, Michael Tokarev wrote: > 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 > 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 > > > 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 > 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 > Can you try with the latest seabios release (v1.7.2.2)? There have been other changes to the dsdt that may have corrected your issue. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] make qemu_cfg_init depend on QEMU_HARDWARE instead of QEMU
On Thu, Jun 13, 2013 at 07:43:03AM +0200, Gerd Hoffmann wrote:
> Gets qemu features like direct kernel boot and boot
> ordering going when seabios runs on coreboot.
>
> Signed-off-by: Gerd Hoffmann
Okay, that looks like it would work. I think the patch below would be
slightly neater though.
-Kevin
>From 5085ada1820f3a17a64f6e3774861622ce613a1f Mon Sep 17 00:00:00 2001
From: Kevin O'Connor
Date: Thu, 13 Jun 2013 20:04:31 -0400
Subject: [PATCH] make qemu_cfg_init depend on QEMU_HARDWARE instead of QEMU
To: seabios@seabios.org
Gets qemu features like direct kernel boot and boot
ordering going when seabios runs on coreboot.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Kevin O'Connor
---
src/paravirt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/paravirt.c b/src/paravirt.c
index e5027d0..d1a5d3e 100644
--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -222,6 +222,9 @@ struct qemu_smbios_header {
static void
qemu_cfg_legacy(void)
{
+if (!CONFIG_QEMU)
+return;
+
// Misc config items.
qemu_romfile_add("etc/show-boot-menu", QEMU_CFG_BOOT_MENU, 0, 2);
qemu_romfile_add("etc/irq0-override", QEMU_CFG_IRQ0_OVERRIDE, 0, 1);
@@ -301,7 +304,7 @@ struct QemuCfgFile {
void qemu_cfg_init(void)
{
-if (!CONFIG_QEMU)
+if (!runningOnQEMU())
return;
// Detect fw_cfg interface.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
On 06/14/13 01:02, Paolo Bonzini wrote: > 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. Basing the decision about derivative or not on internal or complex enough ; well I find that unusable. First, complexity: web services can use very complex XML schemas, and that clearly doesn't make the server derivative of the client, or vice versa. Second, internality: this attribute can be wiped out simply by writing documentation for the data structure (which should be done *anyway*). Once it is documented, it is not internal any longer. However existence of documentation for a wire format between A and B should have absolutely no say in whether codebase A is derivative of codebase B. IANAL of course but I find the FSF's argument biased. (Of course I'm also not buying that linking against a library makes the client application (its own source code, or its dynamically linked binary) derivative of the library. If there are two libraries (especially when released under different licenses) implementing the same API, which one is the application a derivative of?) Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] master is broken
On Thu, Jun 13, 2013 at 08:45:02AM -0400, Kevin O'Connor wrote: > On Thu, Jun 13, 2013 at 11:59:15AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > Switching the list handling broke pci initialization. > > Commit aab42152881dc62b37f1833e79cbdb3dfa51603b seems to be the culprit. > > Thanks. I reverted that patch while I take another look at it. Sorry > about that. Somehow I messed up the hlist_for_each_entry_safe macro. I've corrected that and re-applied the pciinit list conversion patch. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Paolo Bonzini writes: > Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto: >> 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. > > Also having a "bootstrap processor" was certainly not unheard of some > decades ago. Right now we get all sort of SMM hacks instead of adding > more processors, but it's certainly not un-hardware like. It's still not unheard of. This is how power systems work still. However, with PCs, the ACPI tables are generated by/included in the firmware. There's no question about that. > > Maybe we should just have a bytecode interpreter and write the ACPI > generator in that language. :) Indeed, we can even using an existing bytecode like the x86 instruction set and use this VM called KVM to execute it. I hear there are even C compilers for this bytecode ;-) Regards, Anthony Liguori > Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Anthony Liguori wrote: > However, with PCs, the ACPI tables are generated by/included in the > firmware. There's no question about that. I think the key point is that the firmware is developed and delivered by the hardware vendor, and not by an independent source. The firmware is intimately tied to the hardware, and is very much an integral part of all hardware, to the point where the firmware is one of the most prominent downloads made available by all hardware vendors. Don't make the mistake of thinking that firmware for a virtual machine has less to do with the machine just because it's virtual. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] solaris x86 in qemu? [bisected]
14.06.2013 03:47, Kevin O'Connor wrote: >> 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 > > Can you try with the latest seabios release (v1.7.2.2)? There have > been other changes to the dsdt that may have corrected your issue. It's not exactly trivial to switch bioses after splitting out the tables. But I tried the same thing in current qemu git master, which includes 1.7.2.2, and where solaris guest behaves exactly the same -- it stalls with 100% CPU usage somewhere at the beginning of kernel booting. Hmm. Speaking of the splitting. Does the current bios include the the tables which were split into separate files? I mean, what about compatibility between new bios and old qemu and vise versa, where "old" = "before split" and "new" = "after split" ? Thanks! /mjt ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
