SeaBIOS

seabios@seabios.org

5 participants
3802 discussions

[QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
by Amos Kong 03 Jun '13

03 Jun '13

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

6 11

Re: [SeaBIOS] KVM call agenda for 2013-05-28
by Laszlo Ersek 03 Jun '13

03 Jun '13

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

6 17

KVM call agenda for 2013-05-28
by Michael S. Tsirkin 03 Jun '13

03 Jun '13

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

11 35

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
by Gerd Hoffmann 03 Jun '13

03 Jun '13

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

1 0

[SeaBIOS PATCH] boot: fix fw_dev_path pattern for q35-pcihost
by Amos Kong 02 Jun '13

02 Jun '13

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

5 7

How "_cfuncXX_" symbol prefix is added ?
by wx 02 Jun '13

02 Jun '13

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

2 1

Re: [SeaBIOS] [Qemu-devel] What's the impact of enlarging IDE_TIMEOUT ?
by Peter Stuge 01 Jun '13

01 Jun '13

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

1 0

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
by Dave Frodin 01 Jun '13

01 Jun '13

----- Original Message ----- > From: "Kevin O'Connor" <kevin(a)koconnor.net> > To: "Dave Frodin" <dave.frodin(a)se-eng.com> > Cc: "seabios" <seabios(a)seabios.org> > Sent: Friday, May 31, 2013 9:18:21 PM > Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one > > On Fri, May 31, 2013 at 08:32:16AM -0500, Dave Frodin wrote: > > I see now, that's pretty slick. The problem I see with that approach is > > that coreboot would need to add all of these files for a family14 > > mainboard. > [...] > > And all of these files for a family15 mainboard > [...] > > > > Since at build time we only know what cpu family the rom is being > > built for and not (necessarily) what the exact graphics ID is. > > > > The method I proposed would have one family specific "vendev-map.bin" file. > > Yes, but it would be quite difficult to inspect vendev-map.bin. I > think an ascii interface is preferable. > > One could go a level up and make a "symbolic link" type in cbfs (this > is effectively what my patch did). The advantage would be that > cbfstool could display it in a nicer format. > > -Kevin I agree with that, and marc made the same suggestion. I'll put together a new patch next week. Dave

1 0

Re: [SeaBIOS] [Qemu-devel] What's the impact of enlarging IDE_TIMEOUT ?
by Kevin O'Connor 01 Jun '13

01 Jun '13

On Fri, May 31, 2013 at 03:18:56AM +0000, Gonglei (Arei) wrote: > IDE_TIMEOUT is defined 32s. But we encountered its timeout in > some cases, and then loading disk failed in VM. In order to > reduce the probability of timeout, we want to enlarge the > IDE_TIMEOUT, such as 120s. We verified this modification worked > for us. But we are wondering if this modification may cause other > potential issues. Why set IDE_TIMEOUT to 32s? Thanks! The ATA specification specifies the maximum response time for many commands to be 30 seconds. The extra 2 seconds were thrown in for safety. -Kevin

2 1

Re: [SeaBIOS] KVM call agenda for 2013-05-28
by Peter Stuge 01 Jun '13

01 Jun '13

Kevin O'Connor wrote: > one possible way forward would be to split the current SeaBIOS rom > into two roms: "qvmloader" and "seabios". The "qvmloader" would do > the qemu specific platform init (pci init, smm init, mtrr init, bios > tables) and then load and run the regular seabios rom. qvmloader sounds a lot like coreboot. > qvmloader could be committed into the QEMU repo and maintained there. If QEMU really doesn't want anything besides quacking like a PC with BIOS or UEFI (such as quacking like a PC *without* a particular firmware) it makes perfect sense to me to put the complete firmware code into the QEMU repo and never reuse anything else. After all, that's how the proprietary firmware products are managed. Jordan Justen wrote: > Why is updating the ACPI tables in seabios viewed as such a burden? I don't know about burden but to me it just doesn't make any sense to generate ACPI in one component (SeaBIOS) based on configuration for another component (QEMU). ACPI bytes are obviously a function of QEMU configuration. QEMU configuration can be changed through a great many channels, so it makes sense to me that QEMU itself would take care of generating correct ACPI, rather than exporting it's own data structures and pushing the ACPI problem onto the firmware, especially considering the desire for multiple independent firmware implementations. There's some code for dynamic ACPI generation in coreboot already, maybe that can be reused in QEMU to save some effort.. > On the flip side, why is moving the ACPI tables to QEMU such an issue? Maybe because it is such a steaming pile that even the place where it belongs doesn't really want it.. > I think overall I prefer the tables being built in the firmware, > despite the extra thrash. That doesn't make sense to me. :\ Keep in mind: there is firmware and there is firmware.. > Some things, such as the addresses where devices are configured at > are re-programmable in QEMU, so a firmware can decide to use a > different address, and thus invalidate the address qvmloader had > set in the tables. ..there is now talk about a first-stage firmware (qvmloader) which does only hardware init, and then jumps into a second-stage firmware (SeaBIOS) which starts the operating system. I don't expect that anyone would argue for the second-stage firmware to generate ACPI tables if the first-stage firmware would be shared across different second-stage implementations. The above is by the way *exactly* the model coreboot uses since 14 years. Please make an ernest effort to *look into and try to reuse* what *is already there* .. The fear of coreboot is truly amazing. //Peter

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS