Re: [SeaBIOS] [Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU
On Sun, Feb 24, 2013 at 01:00:28PM -0500, Kevin O'Connor wrote: On Sat, Feb 23, 2013 at 04:47:26PM +, David Woodhouse wrote: On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote: IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS) to QEMU and just have QEMU pass the tables to SeaBIOS for it to copy into memory like it does on CSM, coreboot, and Xen. I believe it's on Laszlo's TODO list. Laszlo, what is your plan for doing this? I did a review of the SeaBIOS code to see what information is currently used to generate the ACPI, SMBIOS, MPTABLE, and PIR bios tables. Here's what I came up with: - hardcoded information: Most of the tables are simply hardcoded with various values. This should not be a problem to move to QEMU IIRC SMBIOS has some tables with information about a BIOS. - information passed in from QEMU: RamSize, RamSizeOver4G, fw_cfg (irq0-override, system suspend states, numa memory, additional acpi tables, smbios overrides). These should also be possible to obtain directly within QEMU (though I'm unsure how qemu exposes this information internally). - CPU information: Number of CPUs, the apic id of the CPUs, which CPUs are active, and the cpuid information from the first CPU. Again this should be available in QEMU, but I'm not sure what the internal interfaces look like for obtaining it. - Various hardware probes: The ioapic version, whether or not hpet is present, running on piix4 or ich9, whether or not acpi should be used. Again should be possible to obtain from QEMU with sufficient interfaces. - PCI device info: The list of PCI devices, PCI buses, pin assignments, irq assignments, if hotplug supported, and memory regions. This should mostly be available in QEMU - order of initializing would be important so that the tables were initialized after all PCI devices. Of these, the only thing I see that could be problematic is the PCI irq assignments (used in mptable) and the PCI region space (used in ACPI DSDT _SB.PCI.CRS). These are slightly problematic as they currently rely somewhat on the current SeaBIOS pciinit.c bridge/device setup. However, the mptable irqs is a simple algorithm that could be replicated in QEMU, and it looks to be of dubious value anyway (so could possibly be dropped from the mptable). Also, the PCI region space does not need to be exact, so a heuristic that just ensured it was large enough should suffice. Again IIRC there are still OSes that uses mptable to obtain irq information. See 928d4dffef5c374. Given this, one possible way to migrate the ACPI tables from SeaBIOS would be to: 1 - replace the BDAT PCI range interface in SeaBIOS with a SSDT based template system similar to the way software suspend states are handled in SeaBIOS today. This would eliminate the only runtime references to SeaBIOS memory from ACPI. 2 - relicense the SeaBIOS' acpi.c, mptable.c, pirtable.c, smbios.c code to GPLv2 (from LGPLv3) and copy into QEMU. Only I've claimed a copyright since Fabrice's work (LGPLv2) and I'm willing to relicense. There have been a handful of contributors to these files, but they all look to be regular QEMU contributors so I don't think there would be any objections. Along with the code, the IASL parsing code and associated build python scripts would also need to be copied into QEMU. 3 - update the code to use the internal QEMU interfaces instead of the SeaBIOS interfaces to obtain the information outlined above. 4 - pass the tables from QEMU to SeaBIOS via the fw_cfg interface. The PIR, MPTABLE, and SMBIOS are easy to copy into memory from fw_cfg. The ACPI does have a few tables that are special (RSDP, RSDT, FADT, DSDT, FACS), but it should be easy to detect these and update the pointers in SeaBIOS during the copy to memory. Thoughts? -Kevin -- Gleb. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU
Il 25/02/2013 09:51, Gleb Natapov ha scritto: Of these, the only thing I see that could be problematic is the PCI irq assignments (used in mptable) and the PCI region space (used in ACPI DSDT _SB.PCI.CRS). These are slightly problematic as they currently rely somewhat on the current SeaBIOS pciinit.c bridge/device setup. However, the mptable irqs is a simple algorithm that could be replicated in QEMU, and it looks to be of dubious value anyway (so could possibly be dropped from the mptable). Also, the PCI region space does not need to be exact, so a heuristic that just ensured it was large enough should suffice. Again IIRC there are still OSes that uses mptable to obtain irq information. See 928d4dffef5c374. It should work to use a fixed mptable that overrides interrupts 5/9/10/11, like we do in the MADT. It doesn't need to be just the interrupts that are in use. Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On 02/24/13 19:00, Kevin O'Connor wrote: On Sat, Feb 23, 2013 at 04:47:26PM +, David Woodhouse wrote: On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote: IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS) to QEMU and just have QEMU pass the tables to SeaBIOS for it to copy into memory like it does on CSM, coreboot, and Xen. I believe it's on Laszlo's TODO list. Laszlo, what is your plan for doing this? Didn't have much of a plan until now, just look into it. It seems quite a bit of work (I expect many resubmits to qemu-devel) and I think I'd prefer to start working on it no earlier than March 18th. (Of course if anyone else implements it by then I'll be happy :)) I did a review of the SeaBIOS code to see what information is currently used to generate the ACPI, SMBIOS, MPTABLE, and PIR bios tables. Here's what I came up with: - hardcoded information: Most of the tables are simply hardcoded with various values. This should not be a problem to move to QEMU - information passed in from QEMU: RamSize, RamSizeOver4G, fw_cfg (irq0-override, system suspend states, numa memory, additional acpi tables, smbios overrides). These should also be possible to obtain directly within QEMU (though I'm unsure how qemu exposes this information internally). In the long term I believe everything should be passed as fw_cfg files, one file per table. I'm not sure about the naming convention, but probably something like acpi/SSDT. This already seems quite messy. For example, acpi-dsdt.aml is built as part of SeaBIOS, then installed on the filesystem with qemu. Qemu can load manually specified ACPI tables from files, with the -acpitable switch: do_acpitable_option() [arch_init.c] acpi_table_add() [hw/acpi.c] If no such option is specified, it auto-loads acpi-dsdt.aml (I'm ignoring q35 for now). Then the loaded tables are all exported under one fw_cfg key: pc_init1() [hw/pc_piix.c] pc_acpi_init() [hw/pc.c] acpi_table_add() [hw/acpi.c] pc_memory_init() [hw/pc.c] bochs_bios_init() fw_cfg_add_bytes(..., FW_CFG_ACPI_TABLES, acpi_tables, ...) SeaBIOS then splits/relabels this single blob into sub-blobs, qemu_cfg_legacy() loop qemu_romfile_add(acpi/table%d, QEMU_CFG_ACPI_TABLES, offset, len) Then eg. the DSDT is installed in qemu_platform_setup() acpi_setup() romfile_findprefix() qemu_cfg_read_file() via funcptr fill_dsdt() So it's a seabios-qemu-seabios ping-pong. At first I would export the ACPI table in qemu (install the fw_cfg file) in the same spot where currently the corresponding base info is prepared for SeaBIOS. If a table in SeaBIOS is currently built from several fw_cfg sources, then I'd probably export the qemu replacement in the latest base info spot, verifying if I can still collect earlier pieces of base info. I think we should move forward table-wise... each could take a separate series. Don't know what to do with the -acpitable switch though. A mixture of loaded and autogenerated tables promises trouble. - CPU information: Number of CPUs, the apic id of the CPUs, which CPUs are active, and the cpuid information from the first CPU. Again this should be available in QEMU, but I'm not sure what the internal interfaces look like for obtaining it. I'd just look at what the fw_cfg info is composed from, and re-use it. - Various hardware probes: The ioapic version, whether or not hpet is present, running on piix4 or ich9, whether or not acpi should be used. Again should be possible to obtain from QEMU with sufficient interfaces. - PCI device info: The list of PCI devices, PCI buses, pin assignments, irq assignments, if hotplug supported, and memory regions. This should mostly be available in QEMU - order of initializing would be important so that the tables were initialized after all PCI devices. Of these, the only thing I see that could be problematic is the PCI irq assignments (used in mptable) and the PCI region space (used in ACPI DSDT _SB.PCI.CRS). These are slightly problematic as they currently rely somewhat on the current SeaBIOS pciinit.c bridge/device setup. However, the mptable irqs is a simple algorithm that could be replicated in QEMU, and it looks to be of dubious value anyway (so could possibly be dropped from the mptable). Also, the PCI region space does not need to be exact, so a heuristic that just ensured it was large enough should suffice. Without the CRS stuff efifb wasn't working in OVMF-based guests, so I already had to implement a similar search in OVMF (with ample guidance from Gerd others of course). The series is archived under http://thread.gmane.org/gmane.comp.bios.tianocore.devel/81 The interesting commits are: http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=commitdiff;h=57c0beb609a75349c067075b45cdafce1a1b77f8
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
Laszlo Ersek wrote: I've made peace with generating AML in C source. As it happens, coreboot has a good infrastructure for generating AML at runtime since years already. Of course static tables in coreboot are no better than static tables elsewhere. There are two reasons why moving all this complexity into coreboot makes sense: 1. Significant amounts of code can quite likely be shared between many different hypervisors, since coreboot already shares significant code between many different hardware platforms, never mind the reuse possible across *both* hypervisors and hardware. 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*. I understand that noone really cares about those arguments as long as I don't do their work for them, but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init. Maybe someday someone will actually get the point.. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On 02/25/13 14:43, Peter Stuge wrote: 1. Significant amounts of code can quite likely be shared between many different hypervisors, since coreboot already shares significant code between many different hardware platforms, never mind the reuse possible across *both* hypervisors and hardware. Not really. Virtual hardware can be reconfigured in ways which is impossible on real hardware. This is (party) where the complexity we have in seabios wrt. acpi comes from. 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*. It's a tradeoff. On one hand letting coreboot handle hardware initialialization would reduce the amout of code in seabios we have to maintain. On the other hand adding coreboot as middle man between qemu and seabios would add some complexity to the whole mix. I'm not convinced using coreboot is a clear win, especially with EFI coming. Can coreboot run tianocore as payload? I understand that noone really cares about those arguments as long as I don't do their work for them, If using coreboot would be a clear and obvious win someone would have done that work already. ACPI not working at all in linux guests when using coreboot with seabios payload doesn't exactly encourage exploring that option btw. but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init. Well, *this* discussion is about moving stuff *out* of seabios. Maybe someday someone will actually get the point.. I figured long ago which point you are trying to make. I don't agree though. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
Gerd Hoffmann wrote: 1. Significant amounts of code can quite likely be shared between many different hypervisors, since coreboot already shares significant code between many different hardware platforms, never mind the reuse possible across *both* hypervisors and hardware. Not really. Yes, really. Virtual hardware can be reconfigured in ways which is impossible on real hardware. This is (party) where the complexity we have in seabios wrt. acpi comes from. Yes. And the more flexibility is required the more complex the code gets. It sounds like there will soon be need for a more generic PCI resource allocator, which is another thing that coreboot already has. 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*. It's a tradeoff. On one hand letting coreboot handle hardware initialialization would reduce the amout of code in seabios we have to maintain. On the other hand adding coreboot as middle man between qemu and seabios would add some complexity to the whole mix. What complexities have you run into? coreboot can of course be improved further, but as you may know SeaBIOS gets built by default by the coreboot build process already, so using coreboot wouldn't even add extra steps for a manual build. I'm not convinced using coreboot is a clear win, especially with EFI coming. Can coreboot run tianocore as payload? Work is ongoing to make edk2 a good coreboot payload. It already works for some values of works, but more work is needed. Progress has been fast the last month or so, thanks to efforts by David and Patrick Georgi. ACPI not working at all in linux guests when using coreboot with seabios payload doesn't exactly encourage exploring that option btw. Then the way the QEMU mainboard does ACPI in coreboot needs fixing, which is quite possible because I don't know if someone has actually implemented ACPI at all for QEMU, and if so it is not likely using the more modern facilities but likely to have static ASL. The point is not what is already there, the point is that adding this stuff into SeaBIOS or QEMU for that matter would mean re-inventing *yet another* wheel which is *already* finished in coreboot. but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init. Well, *this* discussion is about moving stuff *out* of seabios. Good point, but it seems to be about moving stuff into each respective hypervisor, when in fact much of that code could probably be common in coreboot without significant effort. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote: I'm not convinced using coreboot is a clear win, especially with EFI coming. Can coreboot run tianocore as payload? It's being worked on. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU
On Mon, Feb 25, 2013 at 10:51:55AM +0200, Gleb Natapov wrote:
On Sun, Feb 24, 2013 at 01:00:28PM -0500, Kevin O'Connor wrote:
I did a review of the SeaBIOS code to see what information is
currently used to generate the ACPI, SMBIOS, MPTABLE, and PIR bios
tables. Here's what I came up with:
- hardcoded information: Most of the tables are simply hardcoded with
various values. This should not be a problem to move to QEMU
IIRC SMBIOS has some tables with information about a BIOS.
Most of the fields in these tables describe hardware, but you are
correct that a few fields describe the firmware. After a quick review
on the SeaBIOS code, I came up with 3 firmware fields populated today:
SMBIOS type 1 bios_starting_address_segment, and ACPI FADT
acpi_enable/acpi_disable fields. The bios_starting_address_segment is
given a bogus value (0xe800) today and I think we can continue to do
that. (There are a couple of other firmware specific fields in the
SMBIOS type 1 struct (bios_characteristics), but they aren't populated
today anyway.) For the SMI acpi_enable/disable fields we can update
the SMI handler to use the values found in the ACPI tables. (Indeed,
the q35 support is already broken here because it declares values that
are different from what the SMI handler is expecting.)
Of these, the only thing I see that could be problematic is the PCI
irq assignments (used in mptable) and the PCI region space (used in
ACPI DSDT _SB.PCI.CRS). These are slightly problematic as they
currently rely somewhat on the current SeaBIOS pciinit.c bridge/device
setup. However, the mptable irqs is a simple algorithm that could be
replicated in QEMU, and it looks to be of dubious value anyway (so
could possibly be dropped from the mptable). Also, the PCI region
space does not need to be exact, so a heuristic that just ensured it
was large enough should suffice.
Again IIRC there are still OSes that uses mptable to obtain irq
information. See 928d4dffef5c374.
Well, it shouldn't be needed for buses other than the root bus.
(Today, SeaBIOS will add an mptable entry for every PCI-PCI bridge,
and I don't think that is correct or useful.) The other info isn't
too painful to put in QEMU - we just need the default PIN# - IRQ
mapping, which can be described with const u8 pci_irqs[4] = { 10, 10,
11, 11 };.
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
