Re: [SeaBIOS] [PATCH v2 3/4] i386: generate pc guest info
b/include/hw/acpi/ich9.h
index b1fe71f..66ab31a 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -45,7 +45,7 @@ typedef struct ICH9LPCPMRegs {
} ICH9LPCPMRegs;
void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
- qemu_irq sci_irq);
+ qemu_irq sci_irq, PcGuestInfo *guest_info);
void ich9_pm_iospace_update(ICH9LPCPMRegs *pm, uint32_t pm_io_base);
extern const VMStateDescription vmstate_ich9_pm;
diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index c5f637b..7428452 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -15,10 +15,11 @@
#include hw/acpi/ich9.h
#include hw/pci/pci_bus.h
+void ich9_lpc_set_guest_info(PcGuestInfo *guest_info);
void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, PcGuestInfo *guest_info);
PCIBus *ich9_d2pbr_init(PCIBus *bus, int devfn, int sec_bus);
i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 56f2e41..b29c8f6 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -10,6 +10,9 @@
#include hw/i386/ioapic.h
#include qemu/range.h
+#include qemu/bitmap.h
+#include sysemu/sysemu.h
+#include hw/pci/pci.h
/* PC-style peripherals (also used by other machines). */
@@ -18,9 +21,35 @@ typedef struct PcPciInfo {
Range w64;
} PcPciInfo;
+/* Matches the value hard-coded in BIOS */
+#define PC_GUEST_PORT_ACPI_PM_BASE 0xb000
+
struct PcGuestInfo {
PcPciInfo pci_info;
bool has_pci_info;
+hwaddr ram_size;
+unsigned apic_id_limit;
+bool apic_xrupt_override;
+bool has_hpet;
+uint64_t numa_nodes;
+uint64_t *node_mem;
+uint64_t *node_cpu;
+DECLARE_BITMAP(found_cpus, MAX_CPUMASK_BITS + 1);
+bool s3_disabled;
+bool s4_disabled;
+uint8_t s4_val;
+DECLARE_BITMAP(slot_hotplug_enable, PCI_SLOT_MAX);
+uint16_t sci_int;
+uint8_t acpi_enable_cmd;
+uint8_t acpi_disable_cmd;
+uint32_t gpe0_blk;
+uint32_t gpe0_blk_len;
+bool fix_rtc;
+bool platform_timer;
+uint64_t mcfg_base;
+const unsigned char *dsdt_code;
+unsigned dsdt_size;
+uint16_t pvpanic_port;
This is all stuff that should be obtained via QOM.
Doing it this way just makes it all that much harder to detangle the
PC initialization mess we already have.
Regards,
Anthony Liguori
FWCfgState *fw_cfg;
};
@@ -114,7 +143,8 @@ DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus
*pci_bus);
void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
ISADevice **rtc_state,
ISADevice **floppy,
- bool no_vmport);
+ bool no_vmport,
+ PcGuestInfo *guest_info);
void pc_init_ne2k_isa(ISABus *bus, NICInfo *nd);
void pc_cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size,
const char *boot_device,
@@ -132,7 +162,8 @@ void ioapic_init_gsi(GSIState *gsi_state, const char
*parent_name);
i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
qemu_irq sci_irq, qemu_irq smi_irq,
- int kvm_enabled, FWCfgState *fw_cfg);
+ int kvm_enabled, FWCfgState *fw_cfg,
+ PcGuestInfo *guest_info);
void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
/* hpet.c */
@@ -194,7 +225,7 @@ static inline bool isa_ne2000_init(ISABus *bus, int base,
int irq, NICInfo *nd)
void pc_system_firmware_init(MemoryRegion *rom_memory);
/* pvpanic.c */
-void pvpanic_init(ISABus *bus);
+void pvpanic_init(ISABus *bus, PcGuestInfo *guest_info);
/* e820 types */
#define E820_RAM1
--
MST
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 4/4] i386: ACPI table generation code from seabios
(*ssdt_pcihp_id - *ssdt_pcihp_start)
+#define ACPI_PCIHP_OFFSET_ADR (*ssdt_pcihp_adr - *ssdt_pcihp_start)
+#define ACPI_PCIHP_OFFSET_EJ0 (*ssdt_pcihp_ej0 - *ssdt_pcihp_start)
+#define ACPI_PCIHP_SIZEOF (*ssdt_pcihp_end - *ssdt_pcihp_start)
+#define ACPI_PCIHP_AML (ssdp_pcihp_aml + *ssdt_pcihp_start)
+
+#define ACPI_SSDT_SIGNATURE 0x54445353 /* SSDT */
+#define ACPI_SSDT_HEADER_LENGTH 36
+
+#include hw/i386/ssdt-misc.hex
+#include hw/i386/ssdt-pcihp.hex
+
+static uint8_t*
+build_notify(uint8_t *ssdt_ptr, const char *name, int skip, int count,
+ const char *target, int ofs)
+{
+int i;
+
+count -= skip;
+
+*(ssdt_ptr++) = 0x14; /* MethodOp */
+ssdt_ptr = acpi_encode_len(ssdt_ptr, 2+5+(12*count), 2);
+memcpy(ssdt_ptr, name, 4);
+ssdt_ptr += 4;
+*(ssdt_ptr++) = 0x02; /* MethodOp */
+
+for (i = skip; count-- 0; i++) {
+*(ssdt_ptr++) = 0xA0; /* IfOp */
+ssdt_ptr = acpi_encode_len(ssdt_ptr, 11, 1);
+*(ssdt_ptr++) = 0x93; /* LEqualOp */
+*(ssdt_ptr++) = 0x68; /* Arg0Op */
+*(ssdt_ptr++) = 0x0A; /* BytePrefix */
+*(ssdt_ptr++) = i;
+*(ssdt_ptr++) = 0x86; /* NotifyOp */
+memcpy(ssdt_ptr, target, 4);
+ssdt_ptr[ofs] = acpi_get_hex(i 4);
+ssdt_ptr[ofs + 1] = acpi_get_hex(i);
+ssdt_ptr += 4;
+*(ssdt_ptr++) = 0x69; /* Arg1Op */
+}
+return ssdt_ptr;
+}
+
+static void patch_pcihp(int slot, uint8_t *ssdt_ptr, uint32_t eject)
+{
+ssdt_ptr[ACPI_PCIHP_OFFSET_HEX] = acpi_get_hex(slot 4);
+ssdt_ptr[ACPI_PCIHP_OFFSET_HEX+1] = acpi_get_hex(slot);
+ssdt_ptr[ACPI_PCIHP_OFFSET_ID] = slot;
+ssdt_ptr[ACPI_PCIHP_OFFSET_ADR + 2] = slot;
+
+/* Runtime patching of ACPI_EJ0: to disable hotplug for a slot,
+ * replace the method name: _EJ0 by ACPI_EJ0_. */
+/* Sanity check */
+assert (!memcmp(ssdt_ptr + ACPI_PCIHP_OFFSET_EJ0, _EJ0, 4));
+
+if (!eject) {
+memcpy(ssdt_ptr + ACPI_PCIHP_OFFSET_EJ0, EJ0_, 4);
+}
+}
+
+static void
+build_ssdt(GArray *table_data, GArray *linker,
+ FWCfgState *fw_cfg, PcGuestInfo *guest_info)
+{
+int acpi_cpus = MIN(0xff, guest_info-apic_id_limit);
+int length = (sizeof(ssdp_misc_aml) /* _S3_ / _S4_ /
_S5_ */
+ + (1+3+4) /* Scope(_SB_) */
+ + (acpi_cpus * ACPI_PROC_SIZEOF) /* procs */
+ + (1+2+5+(12*acpi_cpus)) /* NTFY */
+ + (6+2+1+(1*acpi_cpus)) /* CPON */
+ + (1+3+4) /* Scope(PCI0) */
+ + ((PCI_SLOT_MAX - 1) * ACPI_PCIHP_SIZEOF)/* slots
*/
+ + (1+2+5+(12*(PCI_SLOT_MAX - 1; /* PCNT */
+uint8_t *ssdt = acpi_data_push(table_data, length);
+uint8_t *ssdt_ptr = ssdt;
+
+/* Copy header and encode fwcfg values in the S3_ / S4_ / S5_ packages */
+memcpy(ssdt_ptr, ssdp_misc_aml, sizeof(ssdp_misc_aml));
+if (guest_info-s3_disabled) {
+ssdt_ptr[acpi_s3_name[0]] = 'X';
+}
+if (guest_info-s4_disabled) {
+ssdt_ptr[acpi_s4_name[0]] = 'X';
+} else {
+ssdt_ptr[acpi_s4_pkg[0] + 1] = ssdt[acpi_s4_pkg[0] + 3] =
+guest_info-s4_val;
+}
+
+*(uint32_t*)ssdt_ptr[acpi_pci32_start[0]] =
+cpu_to_le32(guest_info-pci_info.w32.begin);
+*(uint32_t*)ssdt_ptr[acpi_pci32_end[0]] =
+cpu_to_le32(guest_info-pci_info.w32.end - 1);
I don't think you're guaranteed natural alignment here so you need to
use memcpys.
Regards,
Anthony Liguori
+
+if (guest_info-pci_info.w64.end guest_info-pci_info.w64.begin) {
+ssdt_ptr[acpi_pci64_valid[0]] = 1;
+*(uint64_t*)ssdt_ptr[acpi_pci64_start[0]] =
+cpu_to_le64(guest_info-pci_info.w64.begin);
+*(uint64_t*)ssdt_ptr[acpi_pci64_end[0]] =
+cpu_to_le64(guest_info-pci_info.w64.end - 1);
+*(uint64_t*)ssdt_ptr[acpi_pci64_length[0]] =
+cpu_to_le64(guest_info-pci_info.w64.end -
+guest_info-pci_info.w64.begin);
+} else {
+ssdt_ptr[acpi_pci64_valid[0]] = 0;
+}
+
+*(uint16_t *)(ssdt_ptr + *ssdt_isa_pest) =
+cpu_to_le16(guest_info-pvpanic_port);
+
+ssdt_ptr += sizeof(ssdp_misc_aml);
+
+/* build Scope(_SB_) header */
+*(ssdt_ptr++) = 0x10; /* ScopeOp */
+ssdt_ptr = acpi_encode_len(ssdt_ptr, length - (ssdt_ptr - ssdt), 3);
+*(ssdt_ptr++) = '_';
+*(ssdt_ptr++) = 'S';
+*(ssdt_ptr++) = 'B';
+*(ssdt_ptr++) = '_';
+
+/* build Processor object for each processor */
+int i;
+for (i=0; iacpi_cpus; i++) {
+memcpy(ssdt_ptr, ACPI_PROC_AML, ACPI_PROC_SIZEOF);
+ssdt_ptr[ACPI_PROC_OFFSET_CPUHEX] = acpi_get_hex(i 4);
+ssdt_ptr[ACPI_PROC_OFFSET_CPUHEX+1
Re: [SeaBIOS] [PULL 0/9] SCSI updates for 2013-04-13
Pulled. Thanks. Regards, Anthony Liguori ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PULL 0/2] chardev: fix info chardev output
Pulled. Thanks. Regards, Anthony Liguori ___ 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 pbonz...@redhat.com 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] KVM call agenda for 2013-06-11
Michael S. Tsirkin m...@redhat.com writes: On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote: Juan is not available now, and Anthony asked for agenda to be sent early. So here comes: Agenda for the meeting Tue, June 11: - Generating acpi tables, redux Not so much notes as a quick summary of the call: There are the following reasons to generate ACPI tables in QEMU: - sharing code with e.g. ovmf Anthony thinks this is not a valid argument - so we can make tables more dynamic and move away from iasl Anthony thinks this is not a valid reason too, since qemu and seabios have access to same info MST noted several info not accessible to bios. Anthony said they can be added, e.g. by exposing QOM to the bios. - even though most tables are static, hardcoded they are likely to change over time Anthony sees this as justified To summarize, there's a concensus now that generating ACPI tables in QEMU is a good idea. I would say best worst idea ;-) I am deeply concerned about the complexity it introduces but I don't see many other options. Two issues that need to be addressed: - original patches break cross-version migration. Need to fix that. - Anthony requested that patchset is merged together with some new feature. I'm not sure the reasoning is clear: current a version intentionally generates tables that are bug for bug compatible with seabios, to simplify testing. I expect that there will be additional issues that need to be worked out and want to see a feature that actually uses the infrastructure before we add it. It seems clear we have users for this such as hotplug of devices behind pci bridges, so why keep the infrastructure out of tree? It's hard to evaluate the infrastructure without a user. Looking for something additional, smaller as the hotplug patch is a bit big, so might delay merging. Going forward - would we want to move smbios as well? Everyone seems to think it's a good idea. Yes, independent of ACPI, I think QEMU should be generating the SMBIOS tables. Regards, Anthony Liguori -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Michael S. Tsirkin m...@redhat.com writes: This adds support for device hotplug behind pci bridges. Bridge devices themselves need to be pre-configured on qemu command line. One of the goals of this project was to demonstrate the advantages of generating ACPI tables in QEMU. In my opinion, it does this successfully. Since you've gone out of your way to make this difficult to actually review... * This saves the need to provide a new interface for firmware to discover bus number to pci brige mapping Do you mean fw_cfg? The BIOS normally does bus numbering. I see no reason for it not to. * No need for yet another interface to bios to detect qemu version to check if it's safe to activate new code, and to ship multiple table versions: We only care about supporting one version of SeaBIOS. SeaBIOS should only care about supporting one version of QEMU. We're not asking it to support multiple versions. we generated code so we know this is new qemu * Use of glib's GArray makes it much easier to build up tables in code without need for iasl and code patching Adding a dynamic array to SeaBIOS isn't rocket science. I have also tried to address the concerns that Anthony has raised with this approach, please see below. Design: - each bus gets assigned a number 0-255 - generated ACPI code writes this number to a new BSEL register, then uses existing UP/DOWN registers to probe slot status; to eject, write number to BSEL register, then slot into existing EJ This is to address the ACPI spec requirement to avoid config cycle access to any bus except PCI roots. Portability: - Non x86 (or any Linux) platforms don't need any of this code. They can keep happily using SHPC the way they always did. Things to note: - this is on top of acpi patchset posted a month ago, with a small patch adding a core function to walk all pci buses, on top. Can also be found in my git tree git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi - Extensive use of glib completely removes pointer math in new code: we use g_array_append_vals exclusively. There's no code patching in new code. This is in response to comments about security concerns with adding code to qemu. In this sense it is more secure than existing code in hw/acpi/core.c - that can be switched to glib if desired. - New code (not imported from seabios) uses glib to reduce dependency on iasl. With time all code can be rewritted to use glib and avoid iasl, if desired. - As was the case previously, systems that lack working iasl are detected at configure time, pre-generated hex files in source tree are used in this case. This addresses the concern with iasl/big-endian systems. - Compile tested only. Migration is known to be broken - there are a bunch of TODO tags in code. It was agreed on the last qemu conf meeting that this code is posted without looking at migration, with understanding that it is addressed before being merged. Please do not mistake this limitation for a fundamental one - I have a very good idea how to fix it, including cross-version migration. - Cross version migration: when running with -M 1.5 and older, all ACPI table generation should be disabled. We'll present FW_CFG interface compatible with 1.5. So TL;DR, you break a bunch of stuff and introduce a mess of code. It would be less code and wouldn't break anything to add this logic to SeaBIOS. How is this even a discussion? Regards, Anthony Liguori Cc: Jordan Justen jljus...@gmail.com Cc: Anthony Liguori anth...@codemonkey.ws Cc: Laszlo Ersek ler...@redhat.com Cc: Gerd Hoffmann kra...@redhat.com Cc: seabios@seabios.org Cc: David Woodhouse dw...@infradead.org Cc: Kevin O'Connor ke...@koconnor.net Cc: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Michael S. Tsirkin m...@redhat.com --- docs/specs/acpi_pci_hotplug.txt | 8 + include/hw/i386/pc.h | 4 +- hw/i386/acpi-dsdt.dsl| 36 +++- hw/i386/ssdt-pcihp.dsl | 51 - hw/acpi/piix4.c | 145 ++ hw/i386/acpi-build.c | 411 ++- hw/i386/Makefile.objs| 2 +- hw/i386/ssdt-pcihp.hex.generated | 108 -- 8 files changed, 510 insertions(+), 255 deletions(-) delete mode 100644 hw/i386/ssdt-pcihp.dsl delete mode 100644 hw/i386/ssdt-pcihp.hex.generated diff --git a/docs/specs/acpi_pci_hotplug.txt b/docs/specs/acpi_pci_hotplug.txt index a839434..951b99a 100644 --- a/docs/specs/acpi_pci_hotplug.txt +++ b/docs/specs/acpi_pci_hotplug.txt @@ -43,3 +43,11 @@ PCI removability status (IO port 0xae0c
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
David Woodhouse dw...@infradead.org writes: On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote: Internally within QEMU, this initial discussion started by saying that any ACPI generation within QEMU should happen strictly with QOM methods. This was the crux of my argument, if QOM is the only interface we need, everything is there for the firmware to do the same job that QEMU would be doing. That's nice in theory, but I'm not sure how it works as things evolve and new things / new features get exposed. The firmware's *interpretation* of the QOM tree needs to be kept in sync with qemu. Hm, make that: The firmwares' *interpretation*… Let's take a specific, recent example. We fixed the PIIX4 code to actually handle the hard reset on port 0xcf9. We need to fix the ACPI tables to indicate a usable RESET_REG. Very good example. Normally, we try to be bug-for-bug compatible for guests such that -M pc-1.4 would behave exactly the same. In this case, we failed to introduce a property to control this behavior like we should have. If this changes the guest ACPI tables, it definitely should definitely be set based on a property. This is a good example of why this approach is good for QEMU, it helps us catch stuff like this. How is that exposed in the QOM tree, and how does it all work? With qemu exposing ACPI tables in their close-to-final form, it's just fine. Boot with a recent qemu and it's all nice and shiny; boot with an old qemu and it doesn't reset properly. If we did this right in QEMU, we'd have to introduce a QOM property anyway as that's how we trigger differences in machine behavior. And -M pc-1.4 ought to generate the same tables as qemu 1.4 did. Regards, Anthony Liguori But if the firmware has to be updated to interpret the new feature advertised in the QOM tree and translate it into the ACPI table, then we haven't really got much of an improvement. Please explain how this is supposed to work in *practice*. -- dwmw2 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Hi Kevin, On Mon, Jun 10, 2013 at 7:23 PM, Kevin O'Connor ke...@koconnor.net wrote: On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote: Kevin O'Connor ke...@koconnor.net writes: For the MADT table, right now SeaBIOS needs the CPU count. That can be found by counting the number of CPU nodes. Today cpus are unattached so they appear in /machine/unattached but we should put them in a /machine/cpu container for clarity. SeaBIOS needs much more than the CPU count. The madt contains info on each interrupt - its global irq number, the legacy irq number, the acpi defined type of the irq, and the acpi defined flags for the irq. It also contains similar info on each cpu (including apic id), the io apic, and NMIs. See below. QOM is the full representation of the device state so we should not ever need to add additional things to fw_cfg. More likely than not, when SeaBIOS needs more information, it's already there so added functionality will probably Just Work with older QEMUs. I think it would also be useful if you could do the same for a couple DSDT entries (eg, \_SB.PCI0, \_SB.PCI0.ISA) and also describe how you plan to have the guest build the AML from that info. Likewise the slot count should be available too. We hard code slots today but it is something we should model properly. We would model it using QOM of course. Internally within QEMU, this initial discussion started by saying that any ACPI generation within QEMU should happen strictly with QOM methods. This was the crux of my argument, if QOM is the only interface we need, everything is there for the firmware to do the same job that QEMU would be doing. I think we keep talking past each other. You seem to be pointing out that the information seabios uses to patch its hardcoded tables can be passed in via QOM. Agreed, it can. I'm pointing out all the info that is hardcoded in seabios - I don't see how that can be passed via QOM. No, we aren't talking past each other. We both have the same goal. A lot of what is hard coded in SeaBIOS is hard coded in QEMU too. IRQ routing is a good example of that. We want to make this information dynamic. Part of the trouble is that we haven't had a need to not hard code it because this is only information consumed by the BIOS. All the hardcoded data in seabios is a problem, because when it changes (and it frequently does) it requires changes to both QEMU and SeaBIOS and those changes have to be coordinated. The key reason for moving the tables into QEMU is not that it can better patch the tables - the advantage is that it can hardcode the tables that need patching. So let's fix it. It's very easy to add read-only properties to QOM so we can hard code the bits that are in SeaBIOS now as read-only properties. For the MADT table, the per-CPU and IOAPIC info can simply be properties of those devices. We already represent irqs in QOM as integers so I suspect much of the information SeaBIOS needs is already there. I can cite several recent examples of seabios change requests that require changing of the hardcoded tables: liguang wants to add an embedded controller hardware device which requires changes to seabios' dsdt, Corey Minyard wants to add IPMI hardware support (both smbios changes and DSDT changes), and Corey Bryant wants to add TPM hardware support. How do we solve the problem of seabios having a ton of hardcoded information about the qemu hardware, and seabios having to change with the hardware modifications that qemu makes? I think that we can pretty much touch a table once pulling all of the info from QOM and then from a SeaBIOS point of view, never have to touch it again. The benefit is that solving this problem for x86 solves it for other architectures too and also lays the ground work to let a user actually control these bits too. Regards, Anthony Liguori -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Jordan Justen jljus...@gmail.com writes: On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anth...@codemonkey.ws wrote: Michael S. Tsirkin m...@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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Kevin O'Connor ke...@koconnor.net writes: On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote: There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS. The possibility was also raised of a rom that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses). Given the objections to implementing ACPI directly in QEMU, 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. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it. What about a small change to the SeaBIOS build system to allow ACPI table generation to be done via a plugin. This could be as simple as moving acpi.c and *.dsl into the QEMU build tree and then having a way to point the SeaBIOS makefiles to our copy of it. Then the logic is maintained stays in firmware but the churn happens in the QEMU tree instead of the SeaBIOS tree. Regards, Anthony Liguori With both the hardware implementation and acpi descriptions for that hardware in the same source code repository, it would be possible to implement changes to both in a single patch series. The fwcfg entries used to pass data between qemu and qvmloader could also be changed in a single patch and thus those fwcfg entries would not need to be considered a stable interface. The qvmloader code also wouldn't need the 16bit handlers that seabios requires and thus wouldn't need the full complexity of the seabios build. Finally, it's possible that both ovmf and seabios could use a single qvmloader implementation. On the down side, reboots can be a bit goofy today in kvm, and that would need to be settled before something like qvmloader could be implemented. Also, it may be problematic to support passing of bios tables from qvmloader to seabios for guests with only 1 meg of ram. Thoughts? -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Laszlo Ersek ler...@redhat.com writes: On 05/31/13 15:04, Anthony Liguori wrote: Laszlo Ersek ler...@redhat.com writes: On 05/31/13 09:09, Jordan Justen wrote: Due to licensing differences I can't just port code from SeaBIOS to OVMF soapbox :) Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem. It's not optimal for the upstream first principle; still on soapbox OVMF is not Open Source so upstream first doesn't apply. At least, the FAT module is not Open Source. Bullet 8 from the Open Source Definition[1] 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. License from OVMF FAT module[2]: Additional terms: In addition to the forgoing, redistribution and use of the code is conditioned upon the FAT 32 File System Driver and all derivative works thereof being used for and designed only to read and/or write to a file system that is directly managed by: Intel’s Extensible Firmware Initiative (EFI) Specification v. 1.0 and later and/or the Unified Extensible Firmware Interface (UEFI) Forum’s UEFI Specifications v.2.0 and later (together the “UEFI Specifications”); only as necessary to emulate an implementation of the UEFI Specifications; and to create firmware, applications, utilities and/or drivers. [1] http://opensource.org/osd-annotated [2] http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Edk2-fat-driver AFAIK, for the systems that we'd actually want to use OVMF for, a FAT module is a hard requirement. we'd have to backport upstream edk2 patches forever (there's a whole lot of edk2 modules outside of direct OvmfPkg that get built into OVMF.fd -- OvmfPkg only customizes / cherry-picks the full edk2 tree for virtual machines), or to periodically rebase an ever-increasing set of patches. Independently, we need *some* FAT driver (otherwise you can't even boot most installer media), which is where the already discussed worries lie. Whatever solves this aspect is independent of forking all of edk2. It's either Open Source or it's not. It's currently not. I have a hard time sympathesizing with trying to work with a proprietary upstream. Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Correct, but they (presumably) keep rebasing their ever accumulating stuff at least on the periodically refreshed stable edk2 subset (UDK2010, which BTW doesn't include OvmfPkg). This must be horrible for them, but in exchange they get to remain proprietary (which may benefit them commercially). Maintaining a GPL fork seems just as reasonable. Perhaps; diverging from upstream first would hurt for certain. Well I'm suggesting creating a real upstream (that is actually Open Source). Then I'm all for upstream first. In terms of creating a FAT module, the most likely source would seem to be the kernel code and since that's GPL, I don't think it's terribly avoidable to end up with a GPL'd uefi implementation. If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license. Regards, Anthony Liguori /soapbox Thanks for the suggestion :) Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
David Woodhouse dw...@infradead.org writes: On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote: soapbox Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem. Heh. Actually it doesn't need to be a fork. It's modular, and the FAT driver is just a single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere. We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all. So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module. I would propose more of a virtual fork. It could consist of a git repo with the GPL modules + a submodule for edk2. Ideally, there would be no need to actually fork edk2. My assumption is that edk2 won't take GPL code. But does ovmf really need to live in the edk2 tree? If we're going to get serious about supporting OVMF, it we need something that isn't proprietary. -- dwmw2 ¹ If it's GPL, of course, then we mustn't include any *other* binary blobs in our OVMF build. But the whole point in this conversation is that we don't *want* to do that. So that's fine. It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. Without even tackling the issue of GPL code sharing, that is a fundamental problem that needs to be solved if we're going to serious about making changes to QEMU to support it. I think solving the general problem will also enable GPL code sharing though. Regards, Anthony Liguori ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Laszlo Ersek ler...@redhat.com writes: On 05/31/13 09:09, Jordan Justen wrote: Due to licensing differences I can't just port code from SeaBIOS to OVMF soapbox Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem. Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Maintaining a GPL fork seems just as reasonable. /soapbox Regards, Anthony Liguori (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
David Woodhouse dw...@infradead.org writes: On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote: It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right. But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc? And would that be doable in the context of OVMF or would another project need to exist for this purpose? So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source, and replacing the FAT module really isn't that hard. We can only bury our heads in the sand and ship qemu with non-EFI-capable firmware for so long... Which is why I think we need to solve the real problem here. I *know* there's more work to be done. We have SeaBIOS-as-CSM, Jordan has mostly sorted out the NV variable storage, and now the FAT issue is coming up to the top of the pile. But we aren't far from the point where we can realistically say that we want the Open Source OVMF to be the default firmware shipped with qemu. Yes, that's why I'm raising this now. We all knew that we'd have to talk about this eventually. Regards, Anthony Liguori -- dwmw2 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Paolo Bonzini pbonz...@redhat.com writes: Il 31/05/2013 19:06, Anthony Liguori ha scritto: David Woodhouse dw...@infradead.org writes: On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote: It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right. But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc? And would that be doable in the context of OVMF or would another project need to exist for this purpose? I don't think it would be doable in TianoCore. I think it would end up either in distros, or in QEMU. As I think more about it, I think forking edk2 is inevitable. We need a clean repo that doesn't include the proprietary binaries. I doubt upstream edk2 is willing to remove the binaries. But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org. A separate question is whether OVMF makes more sense as part of TianoCore or rather as part of QEMU. I'm not sure if qemu.git is the right location, but we can certainly host an ovmf.git on qemu.git that embeds the scrubbed version of edk2.git. Of course, this would enable us to add GPL code (including a FAT module) to ovmf.git without any impact on upstream edk2. With 75% of the free hypervisors now reunited under the same source repository, the balance is tilting... insert evil laugh :-) Regards, Anthony Liguori Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
Applied. Thanks. Regards, Anthony Liguori ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Jordan Justen jljus...@gmail.com writes: On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@codemonkey.ws wrote: As I think more about it, I think forking edk2 is inevitable. We need a clean repo that doesn't include the proprietary binaries. I doubt upstream edk2 is willing to remove the binaries. No, probably not unless a BSD licensed alternative was available. :) But, in thinking about what might make sense for EDK II with git, one option that should be considered is breaking the top-level 'packages' into separate sub-modules. I had gone so far as to start pushing repos as sub-modules. But, as the effort to convert EDK II to git has stalled (actually never even thought about leaving the ground), I abandoned that approach and went back to just mirroring one EDK II. I could fairly easily re-enable mirror the sub-set of packages needed for OVMF. So, in that case, the FatBinPkg sub-module could easily be dropped from a tree. But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org. I would love to mirror the BaseTools as a sub-package without all the silly windows binaries... What script did you guys use? We did this in git pre-history, now git has a fancy git-filter-branch command that makes it a breeze: http://git-scm.com/book/ch6-4.html Regards, Anthony Liguori -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Gerd Hoffmann kra...@redhat.com writes: On 05/29/13 01:53, Kevin O'Connor wrote: On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote: 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 I didn't see any meeting notes, but I thought it would be worthwhile to summarize the call. This is from memory so correct me if I got anything wrong. Anthony believes that the generation of ACPI tables is the task of the firmware. Reasons cited include security implications of running more code in qemu vs the guest context, I fail to see the security issues here. It's not like the apci table generation code operates on untrusted input from the guest ... But possibly untrusted input from a malicious user. You can imagine something like a IaaS provider that let's a user input arbitrary values for memory, number of nics, etc. It's a stretch of an example, I agree, but the general principle I think is sound: we should push as much work as possible to the least privileged part of the stack. In this case, firmware has much less privileges than QEMU. complexities in running iasl on big-endian machines, We already have a bunch of prebuilt blobs in the qemu repo for simliar reasons, we can do that with iasl output too. possible complexity of having to regenerate tables on a vm reboot, Why tables should be regenerated at reboot? I remember hotplug being mentioned in the call. Hmm? Which hotplugged component needs acpi table updates to work properly? And what is the point of hotplugging if you must reboot the guest anyway to get the acpi updates needed? Details please. See my response to Michael. Also mentioned in the call: architectural reasons, which I understand as real hardware works that way. Correct. But qemu's virtual hardware is configurable in more ways than real hardware, so we have different needs. For example: pci slots can or can't be hotpluggable. On real hardware this is fixed. IIRC this is one of the reasons why we have to patch acpi tables. It's not really fixed. Hardware supports PCI expansion chassises. Multi-node NUMA systems also affect the ACPI tables. overall sloppiness of doing it in QEMU. /me gets the feeling that this is the *main* reason, given that the other ones don't look very convincing to me. Raised that QOM interface should be sufficient. Agree on this one. Ideally the acpi table generation code should be able to gather all information it needs from the qom tree, so it can be a standalone C file instead of being scattered over all qemu. Ack. So my basic argument is why not expose the QOM interfaces to firmware and move the generation code there? Seems like it would be more or less a copy/paste once we had a proper implementation in QEMU. There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS. Certainly an option, but that is a long-term project. Out of curiousity, are there other benefits to using coreboot as a core firmware in QEMU? Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? Regards, Anthony Liguori ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-21
Michael S. Tsirkin m...@redhat.com writes: On Mon, May 20, 2013 at 12:57:47PM +0200, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. Generating acpi tables. Cc'd a bunch of people who might be interested in this topic. Unfortunately I have a conflict this morning so I won't be able to join. I just saw Kevin's response here from last week and I'll respond to it later this morning. Can we post the call for agenda for this call on Fridays in the future? I need more than 24 hours to make sure to keep my calendar clear... Regards, Anthony Liguori Kevin - could you join on Tuesday? There appears a disconnect between the seabios and qemu that a conf call might help resolve. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-21
Michael S. Tsirkin m...@redhat.com writes: On Tue, May 21, 2013 at 07:18:58AM -0500, Anthony Liguori wrote: Michael S. Tsirkin m...@redhat.com writes: On Mon, May 20, 2013 at 12:57:47PM +0200, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. Generating acpi tables. Cc'd a bunch of people who might be interested in this topic. Unfortunately I have a conflict this morning so I won't be able to join. I just saw Kevin's response here from last week and I'll respond to it later this morning. Unfortunate. Let's talk about this on the next slot: next Tuesday, June 4 then. Could you keep your agenda clear on that day please? Ack. Perhaps we could move this call to bimonthly and cancel it less frequently? That will make it easier to reserve calendar time for it. Can we post the call for agenda for this call on Fridays in the future? I need more than 24 hours to make sure to keep my calendar clear... Regards, Anthony Liguori We don't work on Fridays in Israel so that means we'll only be able to respond Sunday, and you'll only see it Monday anyway. Setting agenda Thursday is probably too aggressive? Maybe we could use a wiki page to setup a rolling agenda? Regards, Anthony Liguori Kevin - could you join on Tuesday? There appears a disconnect between the seabios and qemu that a conf call might help resolve. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-21
Michael S. Tsirkin m...@redhat.com writes: On Tue, May 21, 2013 at 09:29:07AM -0500, Anthony Liguori wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, May 21, 2013 at 07:18:58AM -0500, Anthony Liguori wrote: Michael S. Tsirkin m...@redhat.com writes: On Mon, May 20, 2013 at 12:57:47PM +0200, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. Thanks, Juan. Generating acpi tables. Cc'd a bunch of people who might be interested in this topic. Unfortunately I have a conflict this morning so I won't be able to join. I just saw Kevin's response here from last week and I'll respond to it later this morning. Unfortunate. Let's talk about this on the next slot: next Tuesday, June 4 then. Could you keep your agenda clear on that day please? Ack. Perhaps we could move this call to bimonthly and cancel it less frequently? That will make it easier to reserve calendar time for it. I think you mean bi-weekly? If yes, ack. I meant twice a month (or every other week). Regards, Anthony Liguori Can we post the call for agenda for this call on Fridays in the future? I need more than 24 hours to make sure to keep my calendar clear... Regards, Anthony Liguori We don't work on Fridays in Israel so that means we'll only be able to respond Sunday, and you'll only see it Monday anyway. Setting agenda Thursday is probably too aggressive? Maybe we could use a wiki page to setup a rolling agenda? Regards, Anthony Liguori Kevin - could you join on Tuesday? There appears a disconnect between the seabios and qemu that a conf call might help resolve. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann kra...@redhat.com writes: Hi, and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. Huh? As far I know we generate device trees in qemu instead of expecting pseries firmware compile them from fw_cfg information. It depends on what firmware you are using. Of course. On archs which don't use device trees in the first place it doesn't make sense. We don't really generate device trees in general in QEMU. pseries does (thats why the hard libfdt dependency if you want pseries support). arm wants move into that direction too. pseries is a bad example because it's not a real hardware platform. It's emulating what PowerVM does. It's more akin to the xenpv machine than a real piece of hardware. As Peter mentioned, in an ideal world we'd generate them from the QOM graph. Sure. That should happen in the firmware and it could be enabled by adding just a couple fw_cfg commands to navigate the QOM graph (analogs to qom-list and qom-get in QMP). I don't think Peter intended to imply *that* ... Yes, this has been discussed dozens of times in the past. And as I've said in the past, generating device trees belongs in the firmware. It's a firmware/OS interface. It's not just an academic argument though. We want to expose hardware interfaces that are rich enough for firmware to do whatever it needs to do to initialize the system. There are a lot of things that are normally only visible to firmware that we don't emulate today. In exposing this information, we ought to attempt to do so in an architectural neutral way. ACPI is not architectural neutral. You could argue that that's okay because we only need to support two things: ACPI and device trees. But that's not quite right. Device trees very often have platform specific quirks so a generated device tree in common code is not going to have the right set of quirks for any given system. Having a good interface for firmware to generate ACPI tables and device trees solves this problem in a much nicer way. It enables firmware to display whatever type of tree it wants (ACPI or device tree) and also provides the flexibility to implement the necessary quirks for that platform. Regards, Anthony Liguori cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Michael S. Tsirkin m...@redhat.com writes: 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. UEFI obviously can create ACPI tables already so I don't think this is a valid advantage. You could use this argument to say that QEMU should implement int13 or int10 too... - make it easier to add more chipsets without bumping into fw_cfg boundaries. But then you're just introducing a different boundary (the ACPI tables). fw_cfg is a cross-platform interface so it makes a lot more sense to add more features to it to better enumerate the underlying platform. - 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. This has strong analogies to generating device trees and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. 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). I don't think it's a good idea to move BIOS functionality in QEMU. We don't frequently add firmware or chipsets so it seems like we're optimizing for an uncommon scenario here. Regards, Anthony Liguori 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
Re: [SeaBIOS] Updating SeaBIOS on a Chromebook (Was: [PATCH] ps2: disable the keyboard and mouse before flushing the queue)
Thanks Stefan!
I'll give it a try this evening.
Regards,
Anthony Liguori
Stefan Reinauer reina...@google.com writes:
Hi Anthony,
In order to build a working SeaBIOS for the Pixel, you should use our
ChromeOS tree because unfortunately we have not been able to upstream all
the patches we carry around yet.
$ git clone
https://gerrit.chromium.org/gerrit/p/chromiumos/third_party/seabios.git
$ cd seabios
$ git checkout origin/chromeos-2012.05.12
Build it with:
$ cp default.config .config
$ make
Then create a CBFS
# get the PCI option rom
$ wget http://www.coreboot.org/~stepan/pci8086,0166.rom
# Create a dummy bootblock to make cbfstool happy
$ dd if=/dev/zero of=bootblock count=1 bs=64
# Create empty CBFS
$ cbfstool seabios.cbfs create -s $(( 2*1024*1024 )) -B bootblock -m x86
# Add SeaBIOS binary to CBFS
$ cbfstool seabios.cbfs add-payload -f out/bios.bin.elf -n payload -c lzma
# Add VGA option rom to CBFS
$ cbfstool seabios.cbfs add -f pci8086,0166.rom -n pci8086,0166.rom -t
optionrom
# Add additional configuration
$ cbfstool seabios.cbfs add -f bootorder -n bootorder -t raw
$ cbfstool seabios.cbfs add -f boot-menu-wait -n boot-menu-wait -t raw
# Print CBFS inventory
$ cbfstool seabios.cbfs print
# Fix up CBFS to live at 0xffc0. The last four bytes of a CBFS
# image are a pointer to the CBFS master header. Per default a CBFS
# lives at 4G - rom size, and the CBFS master header ends up at
# 0xffa0. However our CBFS lives at 4G-4M and is 2M in size, so
# the CBFS master header is at 0xffdfffa0 instead. The two lines
# below correct the according byte in that pointer to make all CBFS
# parsing code happy. In the long run we should fix cbfstool and
# remove this workaround.
/bin/echo -ne \\0737 | dd of=seabios.cbfs seek=$(( (2*1024*1024) - 2 ))
bs=1 conv=notrunc
That's it. :-)
I also uploaded an image with your change to
http://www.coreboot.org/~stepan/seabios.cbfs.bz2
Flash it on the ChromeBook with:
# cd /tmp
# flashrom -r image.rom
# dd if=seabios.cbfs of=image.rom seek=2 bs=2M conv=notrunc
# flashrom -w image.rom -i RW_LEGACY
On Thu, Apr 25, 2013 at 9:15 AM, ron minnich rminn...@gmail.com wrote:
stefan, how do we fix this?
On Wed, Apr 24, 2013 at 6:36 PM, Anthony Liguori aligu...@us.ibm.com
wrote:
Hi Ron,
I just got a lovely new Pixel and noticed the following problem with
SeaBIOS. Any chance you know how I can update the SeaBIOS firmware to
test this? Or perhaps the person to poke to get fixes included in the
shipped SeaBIOS?
Regards,
Anthony Liguori
-- Forwarded message --
From: Anthony Liguori aligu...@us.ibm.com
To: seabios@seabios.org
Cc: Kevin O'Connor ke...@koconnor.net , Anthony Liguori
aligu...@us.ibm.com
Date: Wed, 24 Apr 2013 20:32:09 -0500
Subject: [PATCH] ps2: disable the keyboard and mouse before flushing the
queue
If SeaBIOS is run as a payload via coreboot (and presumably as a
CSM), then it's possible the keyboard or mouse will still be
enabled. This can lead to data being queued even after the flush
function attempts to clear the queue.
Disabling the keyboard/mouse prior to flushing is pretty standard
in DOS programming so it's not surprising that it's needed here.
I believe this problem manifests with the Chromebook Pixel. People
have reported that sometimes the 'ESC to Select Boot Devices'
doesn't work. I can reproduce this faithfully by holding 'Ctrl-L'
in the firmware screen during SeaBIOS initialization.
I can't test this fix on an actual Pixel because I don't know how
to update SeaBIOS but I have tested the patch under QEMU.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
src/ps2port.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/ps2port.c b/src/ps2port.c
index 9b760fd..2169171 100644
--- a/src/ps2port.c
+++ b/src/ps2port.c
@@ -55,6 +55,12 @@ static int
i8042_flush(void)
{
dprintf(7, i8042_flush\n);
+
+/* Disable the keyboard and mouse to prevent additional data from
+ * being queued. */
+outb(0xad, PORT_PS2_STATUS);
+outb(0xa7, PORT_PS2_STATUS);
+
int i;
for (i=0; iI8042_BUFFER_SIZE; i++) {
u8 status = inb(PORT_PS2_STATUS);
--
1.8.0
--
Stefan Reinauer
Google Inc.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH] ps2: disable the keyboard and mouse before flushing the queue
If SeaBIOS is run as a payload via coreboot (and presumably as a
CSM), then it's possible the keyboard or mouse will still be
enabled. This can lead to data being queued even after the flush
function attempts to clear the queue.
Disabling the keyboard/mouse prior to flushing is pretty standard
in DOS programming so it's not surprising that it's needed here.
I believe this problem manifests with the Chromebook Pixel. People
have reported that sometimes the 'ESC to Select Boot Devices'
doesn't work. I can reproduce this faithfully by holding 'Ctrl-L'
in the firmware screen during SeaBIOS initialization.
I can't test this fix on an actual Pixel because I don't know how
to update SeaBIOS but I have tested the patch under QEMU.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
src/ps2port.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/ps2port.c b/src/ps2port.c
index 9b760fd..2169171 100644
--- a/src/ps2port.c
+++ b/src/ps2port.c
@@ -55,6 +55,12 @@ static int
i8042_flush(void)
{
dprintf(7, i8042_flush\n);
+
+/* Disable the keyboard and mouse to prevent additional data from
+ * being queued. */
+outb(0xad, PORT_PS2_STATUS);
+outb(0xa7, PORT_PS2_STATUS);
+
int i;
for (i=0; iI8042_BUFFER_SIZE; i++) {
u8 status = inb(PORT_PS2_STATUS);
--
1.8.0
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [Qemu PATCH v2] add a boot option to do strict boot
Eric Blake ebl...@redhat.com writes:
On 01/22/2013 08:52 AM, Amos Kong wrote:
Libvirt will need to expose an attribute that lets the user control
whether to use this new option; how do we probe via QMP whether the
new
-boot strict=on command-line option is available?
Hi all,
How about add new info/query command?
(hmp) info strict-boot
on
(qmp) {execute: query-strict-boot}
{return: {state: true}}
It might be not a good solution, I already updated qemu-options.hx,
we can check help message to know if this new option is added or not.
Having libvirt probe the -help output is out of the question. We
already declared that for qemu 1.3 and beyond, ALL command line behavior
must ALSO be probe-able via QMP. I think Anthony had a trick for
testing for existence of various command line options without needing to
add a new query-strict-boot command, but I don't remember what that
trick was.
We need a generic query-config-schema command.
Regards,
Anthony Liguori
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] RFC: Add a new boot parameter to set delay time before seabios retry to boot
Amos Kong ak...@redhat.com writes: Hi all, Seabios supports automatically reboot after X second delay on failed boot [1], I want to add a parameter for qemu, it's used put a boot parameter into romfile for seabios to set the delay time. # qemu ... -boot order=n,menu=on,delay=5 ... Comments suggestions ? Thanks! Why use a file and not just a key/value? Regards, Anthony Liguori [1] commit b8fcf46826e77c835da0ad8127a17895bb2e2fca Author: Kevin O'Connor ke...@koconnor.net Date: Sat May 12 22:12:22 2012 -0400 Automatically reboot after 60 second delay on failed boot. If no valid boot devices are found, display the error for 60 seconds (by default) and then reboot. This enables a periodic retry in case one of the boot devices is still coming online. Signed-off-by: Kevin O'Connor ke...@koconnor.net -- Amos. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PULL 0/1] update qemu seabios / seabios release?
Gerd Hoffmann kra...@redhat.com writes: Hi, This pull updates seabios in qemu to the latest bits from seabios master, so the upcoming 1.2 qemu release gets all the new shiny stuff added recently. I'd like to have a new seabios release for inclusion into qemu 1.2 which is planned for September 1st. So how about this plan: - merge seabios snapshot now (this pull req), so it gets testing in the qemu testing release candidates phase - put seabios into bugfixing freeze too (now or in a few days), fix any issues poping up in testing. - roll out seabios release by end of august, so it can be included into qemu 1.2 We really would need a SeaBIOS release by no later than August 21st to do this. The 1.2 release is on September 1st but we're in hard freeze starting on August 15th. I wouldn't want to make any changes later than the 21st. Regards, Anthony Liguori Anthony? Kevin? Fine are you ok with this? qemu release schedule is here: http://wiki.qemu.org/Planning/1.2 cheers, Gerd Gerd Hoffmann (1): update seabios to latest master pc-bios/bios.bin | Bin 131072 - 131072 bytes roms/seabios |2 +- 2 files changed, 1 insertions(+), 1 deletions(-) The following changes since commit 0b8db8fe15d17a529a5ea90614c11e9f031dfee8: slirp: fix build on mingw32 (2012-08-06 19:31:55 -0500) are available in the git repository at: git://git.kraxel.org/qemu seabios-5a02306 Gerd Hoffmann (1): update seabios to latest master pc-bios/bios.bin | Bin 131072 - 131072 bytes roms/seabios |2 +- 2 files changed, 1 insertions(+), 1 deletions(-) ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug
On 04/19/2012 09:08 AM, Vasilis Liaskovitis wrote: This is a prototype for ACPI memory hotplug on x86_64 target. Based on some earlier work and comments from Gleb. Memslot devices are modeled with a new qemu command line -memslot id=name,start=start_addr,size=sz,node=pxm Hi, For 1.2, I'd really like to focus on refactoring the PC machine as described in this series: https://github.com/aliguori/qemu/commits/qom-rebase.12 I'd like to represent the guest memory as a DIMM device. In terms of this proposal, I would then expect that the i440fx device would have a num_dimms property that controlled how many linkDIMM's it had. Hotplug would consist of creating a DIMM at run time and connecting it to the appropriate link. One thing that's not clear to me is how the start/size fits in. On bare metal, is this something that's calculated by the firmware during start up and then populated in ACPI? Does it do something like take the largest possible DIMM size that it supports and fill out the table? At any rate, I think we should focus on modeling this in QOM verses adding a new option and hacking at the existing memory init code. Regards, Anthony Liguori ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [ANNOUNCE] SeaBIOS 1.7.0
On 04/16/2012 06:35 AM, Gerd Hoffmann wrote: Hi, WinXP guest is unable to find drivers for the video adaptor with -vga std and this vgabios.bin, not even its standard VGA fallback driver. The device in question is detected as Other devices / Video controller (VGA compat.), and its identification looks like: PCI\VEN_1234DEV_SUBSYS_11001AF4REV_00\313C0B0C5010 You'll need to build multiple times with different configurations to get the pci ids right for the various vga variants emulated by qemu. I'll have some build scripts to do that here, just need to rebase and polish them, I'll post the bits ASAP. Do you think you'll get this out in the next couple days? I'd like to move to 1.7.0 and SeaVGABIOS for the 1.1 release if at all possible. Regards, Anthony LIguori cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PULL] Update seabios to 1.6.3.2
On 03/12/2012 09:48 AM, Andreas Färber wrote: Hi Gerd, Am 12.03.2012 14:08, schrieb Gerd Hoffmann: New seabios release on the 1.6.3 stable branch -- lets update. Also add a Makefile + script to simplify seabios updating. That version was released yesterday and I don't see any PATCHes yet... Care to share your build script first before you send a PULL? You also forgot to mention where to pull from. ;) No objection to updating though. I happen to be looking to do this myself, but upon running SeaBIOS through some testing, I ran into: /home/anthony/build/qemu/x86_64-softmmu/qemu-system-x86_64 -kernel bin/vmlinuz-3.0 -initrd .tmp-3349/initramfs-3349.img.gz -append console=ttyS0 seed=38721 -drive file=.tmp-3349/disk-3349.img,if=none,snapshot=on,id=hd0 -device virtio-balloon-pci,addr=03.0 -device virtio-blk-pci,addr=04.0,drive=hd0 -nographic -nodefconfig -m 1G -no-reboot -no-hpet -device virtio-serial -chardev socket,path=.tmp-3349/channel-3349.sock,id=channel0,server,nowait -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 -nodefaults -serial stdio -enable-kvm -pidfile .tmp-3349/pidfile-3349.pid -qmp unix:.tmp-3349/qmpsock-3349.sock,server,nowait KVM internal error. Suberror: 1 emulation failure EAX=aa55 EBX= ECX= EDX= ESI= EDI= EBP= ESP=6f50 EIP=003c EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =c300 000c3000 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= 000fd3a8 0037 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 7c 02 81 02 00 00 00 00 00 00 00 00 3c 00 00 00 00 00 8c c8 8e d8 fa fc e9 91 00 b8 16 00 ba 10 05 ef ba 11 05 ec 66 c1 e0 08 ec 66 c1 e0 08 ec ^Cqemu: terminating on signal 2 How extensively did you test the new seabios changes and are you able to recreate? My GCC is: gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) Regards, Anthony Liguori Andreas Gerd Hoffmann (2): Add seabios build scripts to roms/ Update seabios to 1.6.3.2 pc-bios/bios.bin | Bin 131072 - 131072 bytes roms/Makefile | 10 ++ roms/config.seabios |1 + roms/configure-seabios.sh |5 + roms/seabios |2 +- 5 files changed, 17 insertions(+), 1 deletions(-) create mode 100644 roms/Makefile create mode 100644 roms/config.seabios create mode 100755 roms/configure-seabios.sh ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] insmod virtio-blk is broken in qemu 1.0
On 12/17/2011 09:25 AM, Richard W.M. Jones wrote: On Sat, Dec 17, 2011 at 09:22:45AM -0600, Anthony Liguori wrote: I've even further narrowed it down to the presents or lack of '-vga cirrus'. If you add '-vga cirrus' to the above command line, the guest will boot successfully. Confirmed: Adding -vga cirrus to the command line cures it too. That's a strange one :-) vga sticks out a bit because it's one of the few places where we treat device memory as ram as a performance optimization. The only time vga has been touched in between v0.15 and v1.0 was during the introduction of the memory API. It's this commit: commit d67c3f2cd92aed2247bfa8a9da61a902b7b2ff09 Author: Gerd Hoffmann kra...@redhat.com Date: Wed Aug 10 17:34:13 2011 +0200 seabios: update to master commit 8e301472e324b6d6496d8b4ffc66863e99d7a505 user visible changes in seabios: * ahci is enabled by default (and thus in this build). * bootorder support for ahci. * two-pass pci allocator (orders bars by size for better packing). Signed-off-by: Gerd Hoffmann kra...@redhat.com :04 04 76eb0c81b76563b55cb2bb5c484ccd48b8cfcded 5ec0d65d3a763a5566fe1f4c86269cad6d671020 M pc-bios :04 04 a5a7ea6e297c1e7490b0a2c28a06ce56e5be9449 78adb664d3ea82f1a4dd5ec239887ac5b0168a7f M roms It can be reproduced by using virtio and -vga none with a number of PCI devices. The line below is what I used to bisect and reproduce 100% of the time. It's a 64-bit Fedora 15 guest. $ qemu-system-x86_64 -drive file=/home/anthony/images/fedora.img,if=none,snapshot=on,id=hd0 -device virtio-balloon-pci,addr=03.0 -device virtio-blk-pci,addr=04.0,drive=hd0 -kernel ~/vmlinuz-2.6.38.6-26.rc1.fc15.x86_64 -initrd ~/initramfs-2.6.38.6-26.rc1.fc15.x86_64.img -append root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap ro console=ttyS0 selinux=0 -nographic -nodefconfig -m 1G -no-reboot -no-hpet -device virtio-serial -chardev socket,path=/tmp/foo.sock,id=channel0,server,nowait -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 -nodefaults -serial stdio -enable-kvm My guess it that it has something to do with the changes to the PCI allocator. I've confirmed reverting this commit fixes the problem. Regards, Anthony Liguori Rich. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
