SeaBIOS June 2013

seabios@seabios.org

22 participants
54 discussions

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

by Anthony Liguori

Jordan Justen <jljusten(a)gmail.com> writes: > On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori <anthony(a)codemonkey.ws> wrote: >> "Michael S. Tsirkin" <mst(a)redhat.com> writes: >> >>> On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: >>>> I don't think it's a good idea to move BIOS functionality in QEMU. >>> >>> Just to clarify: generating ACPI tables is not BIOS >>> functionality. It ended up in seabios for historical >>> reasons. >>> >>> A normal scenario for ACPI tables is that they are written >>> in ASL and compiled with IASL. >> >> I wouldn't call this the normal scenario. Some tables are static but >> more tables are dynamic than you'd think. If you're a firmware engineer >> and you have to support dozens of platforms, it's much easier to make >> the tables dynamic than attempt to maintain dozens of ASL descriptions. > > Anthony is right. Firmware for "real" systems contains the tables as > binary aml output from the asl compiler, but also goes through > extensive hoops to tweak the ACPI information. > > On the other hand, "real firmware" doesn't have the luxury of being > able to just download the ACPI tables like fw-cfg might be able to > offer. > > I'm a little concerned that firmware might find a desire to still > customize the tables, and thus the fw-cfg solution might be too > restricting. It does seem to work out okay for other VMM projects > though. (It does seem to be working for Xen in OVMF. But, I'm not > certain how well it is working, since I don't have a Xen setup.) > > I mentioned in the other thread that perhaps QEMU could also consider > making the ACPI code available under some 'appropriate' license, which > would allow firmware writers to leverage the code directly if desired. > Perhaps a dual/multi license situation for the relevant files? Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree? I think the only solution to the licensing problem is a GPL-friendly UEFI build... Regards, Anthony Liguori > > But, if the fw-cfg route works, then it seems the easiest option for > firmware writers. > > -Jordan

8 years, 3 months

[PATCH RFC 00/13] qemu: generate acpi tables for the guest

by Michael S. Tsirkin

This patchset moves all generation of ACPI tables from guest BIOS to the hypervisor. Although ACPI tables come from a system BIOS on real hw, it makes sense that the ACPI tables are coupled with the virtual machine, since they have to abstract the x86 machine to the OS's. Several future developments that this will enable: - make it easier to use alternative firmware: any firmware can just load the ACPI tables from QEMU. case in point OVMF. - make it easier to add more chipsets without bumping into fw_cfg boundaries. - describe a complex configuration e.g. a bridged PCI topology to enable acpi hotplug of devices behind a PCI bridge, or for multi-root topology. If you look at the actual code: i386: imports ACPI table generation code from seabios you will see that it's more complex than it needs to be, with lots of low level casts and similar tricks. There's also a bit of duplication where we already declare similar acpi structures in qemu. This is the result of code being a direct port from seabios. Laszlo's patch (build ACPI MADT (APIC) for fw_cfg) shows how this will be cleaned up by follow-up work. I think it's best to do it in this order: port code directly, and apply cleanups and reduce duplication that results, on top. This way it's much easier to see that we don't introduce regressions. In particular, for a simple VM with piix, I booted a guest on qemu with and without the change, and verified that ACPI tables are unchanged except for trivial pointer address changes. Such binary compatibility makes it easier to be confident that this change won't break things. So the idea is Laszlo's patchset (patches 2-7) will be rebased on top of this patchset, this way we'll get small cleanup changes, where each step is easy to verify as not changing anything from Guest POV. One issue this patchset creates is cross-version migration. Specifically migration to qemu 1.5 will not work if it happens while bios is accessing fw_cfg when we migrate. This is a general problem of the fw_cfg implementation, I plan to extend fw_cfg implementation to address this. I plan to test q35 and numa setups before I submit this for inclusion, in a similar way. git trees, for those interested in testing this: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi git://git.kernel.org/pub/scm/virt/kvm/mst/seabios.git acpi bios patchset will be posted tomorrow (need to clean up the commit log a bit). Laszlo Ersek (1): refer to FWCfgState explicitly Michael S. Tsirkin (12): apic: rename apic specific bitopts hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h fw_cfg: move typedef to qemu/typedefs.h i386: add ACPI table files from seabios acpi: add rules to compile ASL source acpi: pre-compiled ASL files range: add Range structure i386: add bios linker/loader i386: generate pc guest info pc: pass PCI hole ranges to Guests i386: ACPI table generation code from seabios pc: reuse guest info for legacy fw cfg configure | 9 +- hw/acpi/ich9.c | 7 +- hw/acpi/piix4.c | 44 +- hw/core/loader.c | 2 +- hw/i386/Makefile.objs | 27 + hw/i386/acpi-build.c | 685 ++++ hw/i386/acpi-dsdt-cpu-hotplug.dsl | 93 + hw/i386/acpi-dsdt-dbug.dsl | 41 + hw/i386/acpi-dsdt-hpet.dsl | 51 + hw/i386/acpi-dsdt-isa.dsl | 117 + hw/i386/acpi-dsdt-pci-crs.dsl | 105 + hw/i386/acpi-dsdt.dsl | 343 ++ hw/i386/acpi-dsdt.hex.generated | 4409 ++++++++++++++++++++ hw/i386/bios-linker-loader.c | 155 + hw/i386/multiboot.c | 2 +- hw/i386/multiboot.h | 4 +- hw/i386/pc.c | 159 +- hw/i386/pc_piix.c | 28 +- hw/i386/pc_q35.c | 14 +- hw/i386/q35-acpi-dsdt.dsl | 452 +++ hw/i386/q35-acpi-dsdt.hex.generated | 7346 ++++++++++++++++++++++++++++++++++ hw/i386/ssdt-misc.dsl | 73 + hw/i386/ssdt-misc.hex.generated | 190 + hw/i386/ssdt-pcihp.dsl | 51 + hw/i386/ssdt-pcihp.hex.generated | 108 + hw/i386/ssdt-proc.dsl | 63 + hw/i386/ssdt-proc.hex.generated | 134 + hw/intc/apic.c | 42 +- hw/isa/lpc_ich9.c | 11 +- hw/mips/mips_malta.c | 2 +- hw/pci-host/q35.c | 5 + hw/sparc/sun4m.c | 6 +- hw/sparc64/sun4u.c | 2 +- include/hw/acpi/ich9.h | 2 +- include/hw/i386/acpi-build.h | 9 + include/hw/i386/apic.h | 2 + include/hw/i386/bios-linker-loader.h | 26 + include/hw/i386/ich9.h | 3 +- include/hw/i386/pc.h | 67 +- include/hw/loader.h | 3 +- include/hw/nvram/fw_cfg.h | 2 +- include/hw/pci-host/q35.h | 2 + include/qemu/range.h | 22 + include/qemu/typedefs.h | 2 + scripts/acpi_extract.py | 362 ++ scripts/acpi_extract_preprocess.py | 52 + scripts/update-acpi.sh | 4 + 47 files changed, 15248 insertions(+), 90 deletions(-) create mode 100644 hw/i386/acpi-build.c create mode 100644 hw/i386/acpi-dsdt-cpu-hotplug.dsl create mode 100644 hw/i386/acpi-dsdt-dbug.dsl create mode 100644 hw/i386/acpi-dsdt-hpet.dsl create mode 100644 hw/i386/acpi-dsdt-isa.dsl create mode 100644 hw/i386/acpi-dsdt-pci-crs.dsl create mode 100644 hw/i386/acpi-dsdt.dsl create mode 100644 hw/i386/acpi-dsdt.hex.generated create mode 100644 hw/i386/bios-linker-loader.c create mode 100644 hw/i386/q35-acpi-dsdt.dsl create mode 100644 hw/i386/q35-acpi-dsdt.hex.generated create mode 100644 hw/i386/ssdt-misc.dsl create mode 100644 hw/i386/ssdt-misc.hex.generated create mode 100644 hw/i386/ssdt-pcihp.dsl create mode 100644 hw/i386/ssdt-pcihp.hex.generated create mode 100644 hw/i386/ssdt-proc.dsl create mode 100644 hw/i386/ssdt-proc.hex.generated create mode 100644 include/hw/i386/acpi-build.h create mode 100644 include/hw/i386/bios-linker-loader.h create mode 100755 scripts/acpi_extract.py create mode 100755 scripts/acpi_extract_preprocess.py create mode 100644 scripts/update-acpi.sh -- MST

8 years, 3 months

[PATCH 1/2] config: allow DEBUG_IO for !QEMU

by Gerd Hoffmann

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..100481b 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 && (PlatformRunningOn & PF_QEMU)) // Send character to debug port. outb(c, GET_GLOBAL(DebugOutputPort)); if (c == '\n') -- 1.7.9.7

8 years, 3 months

[QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path

by Amos Kong

Recent virtio refactoring in QEMU made virtio-bus become the parent bus of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation, typename will be added to fw_dev_path by default, the new fw_dev_path could not be identified by seabios. It causes that bootindex parameter of scsi device doesn't work. This patch implements get_fw_dev_path() in BusClass, it will be called if bus doesn't implement the method, tyename will be added to fw_dev_path. If the implemented method returns NULL, nothing will be added to fw_dev_path. It also implements virtio_bus_get_fw_dev_path() to return NULL. Then QEMU will still pass original style of fw_dev_path to seabios. Signed-off-by: Amos Kong <akong(a)redhat.com> -- v2: only add nothing to fw_dev_path when get_fw_dev_path() is implemented and returns NULL. then it will not effect other devices don't have get_fw_dev_path() implementation. v3: implement default get_fw_dev_path() in BusClass --- hw/core/qdev.c | 10 +++++++++- hw/virtio/virtio-bus.c | 6 ++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 6985ad8..9190a7e 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size) l += snprintf(p + l, size - l, "%s", d); g_free(d); } else { - l += snprintf(p + l, size - l, "%s", object_get_typename(OBJECT(dev))); + return l; } } l += snprintf(p + l , size - l, "/"); @@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj) QTAILQ_INIT(&bus->children); } +static char *default_bus_get_fw_dev_path(DeviceState *dev) +{ + return g_strdup(object_get_typename(OBJECT(dev))); +} + static void bus_class_init(ObjectClass *class, void *data) { + BusClass *bc = BUS_CLASS(class); + class->unparent = bus_unparent; + bc->get_fw_dev_path = default_bus_get_fw_dev_path; } static void qbus_finalize(Object *obj) diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c index ea2e11a..6849a01 100644 --- a/hw/virtio/virtio-bus.c +++ b/hw/virtio/virtio-bus.c @@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState *dev) return qdev_get_dev_path(proxy); } +static char *virtio_bus_get_fw_dev_path(DeviceState *dev) +{ + return NULL; +} + static void virtio_bus_class_init(ObjectClass *klass, void *data) { BusClass *bus_class = BUS_CLASS(klass); bus_class->get_dev_path = virtio_bus_get_dev_path; + bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path; } static const TypeInfo virtio_bus_info = { -- 1.8.1.4

8 years, 3 months

Re: [SeaBIOS] KVM call agenda for 2013-05-28

by Laszlo Ersek

On 05/31/13 09:09, Jordan Justen wrote: > Why is updating the ACPI tables in seabios viewed as such a burden? > Either qemu does it, or seabios... (And, OVMF too, but I don't think > you guys are concerned with that. :) I am :) > On the flip side, why is moving the ACPI tables to QEMU such an issue? > It seems like Xen and virtualbox both already do this. Why is running > iasl not an issue for them? I think something was mentioned about iasl having problems on BE machines? I could be easily wrong but I *guess* qemu's hosts x targets (emulate what on what) set is a proper superset of xen's and virtualbox's. Presumably if you want to run an x86 guest on a MIPS host, and also want to build qemu on the same MIPS (or SPARC) host, you'd have to run iasl there too. > Maybe we are doing lots of things horribly wrong in our OVMF ACPI > tables :) Impossible. :) In earnest, I think what we have now is (mostly) correct, just not extensive / flexible enough. No support for PCI hotplug or CPU hotplug, none for S3 (although all of these tie into UEFI deeply), no MTRR setup, no MPTABLE; let alone a non-PIIX chipset. (Well maybe I shouldn't lump these under the "ACPI umbrella".) > but I haven't seen it as much of a burden. (Of course, > Laszlo has helped out with many of the ACPI changes in OVMF, so his > opinion should be taken into consideration too. :) It hasn't been a "burden" in the sense of me not liking the activity; I actually like fiddling with knobs. It has certainly been extra work to bring OVMF's ACPI tables closer to SeaBIOS's functionality / flexibility (and we still lag behind it quite.). Due to licensing differences I can't just port code from SeaBIOS to OVMF (and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.) It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was). I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools. Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define & initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.) AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future. Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much. Thanks, Laszlo

8 years, 3 months

KVM call agenda for 2013-05-28

by Michael S. Tsirkin

Juan is not available now, and Anthony asked for agenda to be sent early. So here comes: Agenda for the meeting Tue, May 28: - Generating acpi tables - Switching the call to a bi-weekly schedule Please, send any topic that you are interested in covering. Thanks, MST -- MST

8 years, 3 months

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

by Gerd Hoffmann

On 06/01/13 01:01, Jordan Justen wrote: > On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann <kraxel(a)redhat.com> wrote: >> Hi, >> >>> I guess -bios would load coreboot. Coreboot would siphon the data >>> necessary for ACPI table building through the current (same) fw_cfg >>> bottleneck, build the tables, >> >> Yes. > > So, this is really about making coreboot+seabios the default QEMU > firmware, and making seabios depend on being a coreboot payload? I still think it's better to simply have qemu generate the acpi tables, but if that isn't going to be accepted we should seriously consider & evaluate switching to coreboot. >>> load the boot firmware (SeaBIOS or OVMF or >>> something else -- not sure how to configure that), > > It wouldn't be loading OVMF. It would be loading CorebootPkg. Yep. Some OVMF bits would be needed though (virtio drivers, qemu boot priority support, ...). cheers, Gerd

8 years, 3 months

[SeaBIOS PATCH] boot: fix fw_dev_path pattern for q35-pcihost

by Amos Kong

Bootindex string passed from qemu: /q35-pcihost@i0cf8/ethernet@2/ethernet-phy@0 We match pci domain by "/pci@i0cf8" in SeaBIOS, but fw_dev_path prefix of q35 is "/q35-pcihost@i0cf8". So bootindex in qemu commandline doesn't work if it uses q35 machine type. This patch fixes the pattern to match both original pc-i440fx & q35 Signed-off-by: Amos Kong <akong(a)redhat.com> --- src/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/boot.c b/src/boot.c index cd9d784..f30d47e 100644 --- a/src/boot.c +++ b/src/boot.c @@ -97,7 +97,7 @@ find_prio(const char *glob) return -1; } -#define FW_PCI_DOMAIN "/pci@i0cf8" +#define FW_PCI_DOMAIN "/*pci*@i0cf8" static char * build_pci_path(char *buf, int max, const char *devname, struct pci_device *pci) -- 1.8.1.4

8 years, 3 months

How "_cfuncXX_" symbol prefix is added ?

by wx

Sorry for previous wrong mail Title~~ ------------------------------------ hi,kevin there is patch from 0.6.1 to 0.6.2 f3fe3aa7a0ccb881e659a4281d6f0a0bb5c33cc5 (Require a "_cfuncXX_" symbol prefix for inter-mode c function references.) how _cfunc32flat_, _cfunc32seg_ prefix are added to C function symbols ? It seems that macro "VISIBLE32FLAT" or "VISIBLE32SEG" can not do this or which gcc attributes influence it ? post.c void VISIBLE32FLAT _start(void) { romleyout.S _cfunc32flat__start thanks! wx

8 years, 3 months

Re: [SeaBIOS] [Qemu-devel] What's the impact of enlarging IDE_TIMEOUT ?

by Peter Stuge

Fred . wrote: > Sounds like something that should be commented in the source code. Sounds like something that even you could send a patch for. //Peter

8 years, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2013