Re: [SeaBIOS] [PATCH v2 4/4] i386: ACPI table generation code from seabios
intsrcovr++;
> +}
> +
> +local_nmi = (void*)intsrcovr;
> +local_nmi->type = ACPI_APIC_LOCAL_NMI;
> +local_nmi->length = sizeof(*local_nmi);
> +local_nmi->processor_id = 0xff; /* all processors */
> +local_nmi->flags= cpu_to_le16(0);
> +local_nmi->lint = 1; /* ACPI_LINT1 */
> +local_nmi++;
> +
> +build_header(linker, table_data,
> + (void*)madt, ACPI_APIC_SIGNATURE,
> + (void*)local_nmi - (void*)madt, 1);
> +}
> +
> +/* Encode a hex value */
> +static inline char acpi_get_hex(uint32_t val) {
> +val &= 0x0f;
> +return (val <= 9) ? ('0' + val) : ('A' + val - 10);
> +}
> +
> +/* Encode a length in an SSDT. */
> +static uint8_t *
> +acpi_encode_len(uint8_t *ssdt_ptr, int length, int bytes)
> +{
> +switch (bytes) {
> +default:
> +case 4: ssdt_ptr[3] = ((length >> 20) & 0xff);
> +case 3: ssdt_ptr[2] = ((length >> 12) & 0xff);
> +case 2: ssdt_ptr[1] = ((length >> 4) & 0xff);
> +ssdt_ptr[0] = (((bytes - 1) & 0x3) << 6) | (length & 0x0f);
> +break;
> +case 1: ssdt_ptr[0] = length & 0x3f;
> +}
> +return ssdt_ptr + bytes;
> +}
> +
> +#include "hw/i386/ssdt-proc.hex"
> +
> +/* 0x5B 0x83 ProcessorOp PkgLength NameString ProcID */
> +#define ACPI_PROC_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2)
> +#define ACPI_PROC_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4)
> +#define ACPI_PROC_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start)
> +#define ACPI_PROC_SIZEOF (*ssdt_proc_end - *ssdt_proc_start)
> +#define ACPI_PROC_AML (ssdp_proc_aml + *ssdt_proc_start)
> +
> +/* 0x5B 0x82 DeviceOp PkgLength NameString */
> +#define ACPI_PCIHP_OFFSET_HEX (*ssdt_pcihp_name - *ssdt_pcihp_start + 1)
> +#define ACPI_PCIHP_OFFSET_ID (*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*acp
Re: [SeaBIOS] [PATCH v2 3/4] i386: generate pc guest info
pci_bus, piix4_devfn + 3, 0x1100,
> - isa_get_irq(NULL, 9), NULL, 0, NULL);
> + isa_get_irq(NULL, 9), NULL, 0, NULL, NULL);
> /* TODO: Populate SPD eeprom data. */
> smbus_eeprom_init(smbus, 8, NULL, 0);
> pit = pit_init(isa_bus, 0x40, 0, NULL);
> diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
> index 792d8e4..7af713a 100644
> --- a/hw/misc/pvpanic.c
> +++ b/hw/misc/pvpanic.c
> @@ -101,25 +101,27 @@ static void pvpanic_isa_realizefn(DeviceState *dev,
> Error **errp)
> isa_register_ioport(d, &s->io, s->ioport);
> }
>
> -static void pvpanic_fw_cfg(ISADevice *dev, FWCfgState *fw_cfg)
> +static void pvpanic_guest_info(ISADevice *dev, PcGuestInfo *guest_info)
> {
> PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
> uint16_t *pvpanic_port = g_malloc(sizeof(*pvpanic_port));
> *pvpanic_port = cpu_to_le16(s->ioport);
>
> -fw_cfg_add_file(fw_cfg, "etc/pvpanic-port", pvpanic_port,
> +fw_cfg_add_file(guest_info->fw_cfg, "etc/pvpanic-port", pvpanic_port,
> sizeof(*pvpanic_port));
> +
> +guest_info->pvpanic_port = s->ioport;
> }
>
> -void pvpanic_init(ISABus *bus)
> +void pvpanic_init(ISABus *bus, PcGuestInfo *guest_info)
> {
> ISADevice *dev;
> -FWCfgState *fw_cfg = fw_cfg_find();
> +FWCfgState *fw_cfg = guest_info->fw_cfg;
> if (!fw_cfg) {
> return;
> }
> dev = isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE);
> -pvpanic_fw_cfg(dev, fw_cfg);
> +pvpanic_guest_info(dev, guest_info);
> }
>
> static Property pvpanic_isa_properties[] = {
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 13148ed..667bd20 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -260,6 +260,7 @@ static int mch_init(PCIDevice *d)
> */
> mch->guest_info->pci_info.w32.begin = MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT +
> MCH_HOST_BRIDGE_PCIEXBAR_MAX;
> +mch->guest_info->mcfg_base = MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT;
>
> /* setup pci memory regions */
> memory_region_init_alias(&mch->pci_hole, "pci-hole",
> diff --git a/include/hw/acpi/ich9.h 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;
> +uin
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] [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] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Paolo Bonzini writes: > Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto: >> Two points >> 1. You never explained what you mean by un-hardware like. >> >>Currently bios is in a ROM device, and it has a >>template for ACPI tables together with it. >>This simply moves the tables to a separate ROM >>device (FW CFG), and generalizes the template using >>the linker interface. >>One ROM is hardware-like but two is un-hardware like? >> >>ACPI tables are static so it's likely lots of >>hardware has at least some of them pre-formatted in flash, >>then tweak some things like SRAT a bit. > > Also having a "bootstrap processor" was certainly not unheard of some > decades ago. Right now we get all sort of SMM hacks instead of adding > more processors, but it's certainly not un-hardware like. It's still not unheard of. This is how power systems work still. However, with PCs, the ACPI tables are generated by/included in the firmware. There's no question about that. > > Maybe we should just have a bytecode interpreter and write the ACPI > generator in that language. :) Indeed, we can even using an existing bytecode like the x86 instruction set and use this VM called KVM to execute it. I hear there are even C compilers for this bytecode ;-) Regards, Anthony Liguori > Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-06-11
"Michael S. Tsirkin" 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
Hi Kevin, On Mon, Jun 10, 2013 at 7:23 PM, Kevin O'Connor wrote: > On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote: >> Kevin O'Connor 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] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
David Woodhouse 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
"Michael S. Tsirkin" 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 > Cc: Anthony Liguori > Cc: Laszlo Ersek > Cc: Gerd Hoffmann > Cc: seabios@seabios.org > Cc: David Woodhouse > Cc: Kevin O'Connor > Cc: Peter Maydell > Signed-off-by: Michael S. Tsirkin > --- > 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 > d
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Jordan Justen writes: > On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori > wrote: >> "Michael S. Tsirkin" 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
Jordan Justen writes: > On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori > 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] [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
Paolo Bonzini writes: > Il 31/05/2013 19:06, Anthony Liguori ha scritto: >> David Woodhouse 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... :-) Regards, Anthony Liguori > > Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
David Woodhouse 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
Laszlo Ersek writes: > On 05/31/13 09:09, Jordan Justen wrote: > > Due to licensing differences I can't just port code from SeaBIOS to > OVMF 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. 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 writes: > On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote: >> >> >> >> 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 writes: > On 05/31/13 15:04, Anthony Liguori wrote: >> Laszlo Ersek writes: >> >>> On 05/31/13 09:09, Jordan Justen wrote: >>> >>> Due to licensing differences I can't just port code from SeaBIOS to >>> OVMF >> >> > > :) > >> 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; 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 > >> > > 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
Kevin O'Connor 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
Gerd Hoffmann 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-28
"Michael S. Tsirkin" writes: > On Tue, May 28, 2013 at 07:53:09PM -0400, 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, complexities in running iasl on >> big-endian machines, possible complexity of having to regenerate >> tables on a vm reboot, overall sloppiness of doing it in QEMU. Raised >> that QOM interface should be sufficient. >> >> Kevin believes that the bios table code should be moved up into QEMU. >> Reasons cited include the churn rate in SeaBIOS for this QEMU feature >> (15-20% of all SeaBIOS commits since integrating with QEMU have been >> for bios tables; 20% of SeaBIOS commits in last year), complexity of >> trying to pass all the content needed to generate the tables (eg, >> device details, power tree, irq routing), complexity of scheduling >> changes across different repos and synchronizing their rollout, >> complexity of implemeting the code in both OVMF and SeaBIOS. Kevin >> wasn't aware of a requirement to regenerate acpi tables on a vm >> reboot. > > I think this last one is based on a misunderstanding: it's based > on assumption that we we change hardware by hotplug > we should regenerate the tables to match. > But there's no management that can take advantage of > this. > Two possible reasonable things we can tell management: > - hotplug for device XXX is not supported: restart qemu > to make guest use the device > - hotplug for device XXX is supported This introduces an assumption: that the device model never radically changes across resets. Why should this be true? Shouldn't we be allowed to increase the amount of memory the guest has across reboots? That's equivalent to adding another DIMM after power off. Not generating tables on reset does limit what we can do in a pretty fundamental way. Even if you can argue it in the short term, I don't think it's viable in the long term. 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" writes: > On Tue, May 21, 2013 at 09:29:07AM -0500, Anthony Liguori wrote: >> "Michael S. Tsirkin" writes: >> >> > On Tue, May 21, 2013 at 07:18:58AM -0500, Anthony Liguori wrote: >> >> "Michael S. Tsirkin" 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] KVM call agenda for 2013-05-21
"Michael S. Tsirkin" writes: > On Tue, May 21, 2013 at 07:18:58AM -0500, Anthony Liguori wrote: >> "Michael S. Tsirkin" 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" 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] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann 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" 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. A lot of what you'd consider to be static is actually dynamic in a multi-node system. > The tables are then stored > in some ROM device - most of them, except FACP, can actually > be mapped directly from ROM if necessary. > > You won't normally find real BIOS probing PCI slots for > hotplug support and writing EJ0 methods dynamically - > instead the assumption is that hardware (in this case QEMU) > supplies its own static description in form of ACPI tables. Actually, this is a very good example. In more modern boxes like Flex, there's a PCI-Express backplane that all of the nodes are connected to with a common set of slots for all nodes. You can configure in firmware how the slots map to each node. I can share an acpi dump from one of these systems when after I head into the office this morning. This is what's nice about a switched PCI complex. You have tremendous amounts of flexibility in how you set things up. Regards, Anthony Liguori > My patchset uses FW_CFG as such a ROM device. It would be > easy to switch to something else instead of FW_CFG. > Is this what you are suggesting? > > -- > MST ___ 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 writes: > Hi, > >>> 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. > > Yea, but it doesn't do all the patching seabios does, so some features > simply don't work. Generating the tables in qemu instead will zap those > differnces and will make it alot easier to bring all firmware images > (seabios, ovmf, coreboot, ...) to feature parity without duplicating the > code needed for that in all firmwares. The fact that different firmwares duplicate functionality is the based on the fact that the different firmwares inheritently duplication functionality by the virtue of being different projects. >> You could use this argument to say that QEMU should implement int13 or >> int10 too... > > This is comparing apples and oranges. > >> This has strong analogies to generating device trees > > Indeed, both acpi and device trees describe the hardware emulated by > qemu. Comparing acpi + device trees makes alot more sense than > comparing acpi with int10 ... > >> 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. We don't really generate device trees in general in QEMU. As Peter mentioned, in an ideal world we'd generate them from the QOM graph. 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). 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" 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 >
[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
---
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; ihttp://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] ps2: disable the keyboard and mouse before flushing the queue
Kevin O'Connor writes:
> On Wed, Apr 24, 2013 at 08:32:09PM -0500, Anthony Liguori wrote:
>> 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.
>
> Thanks. I don't understand why keyboard/mouse events would be a
> problem. Those events should get discarded with the "Discarding ps2
> data %02x (status=%02x)" message. (The role of the flush is to make
> sure there are no i8042 command responses pending - I don't think
> keyboard/mouse events are a problem.)
This is much too late. I think what's happening is:
>/* flush incoming keys */
>int ret = i8042_flush();
>if (ret)
>return;
This drains the PS/2 queue but if the keyboard is enabled, then more
data can appear in the queue.
>// Controller self-test.
>u8 param[2];
>ret = i8042_command(I8042_CMD_CTL_TEST, param);
>if (ret)
>return;
>if (param[0] != 0x55) {
>dprintf(1, "i8042 self test failed (got %x not 0x55)\n", param[0]);
>return;
>}
The patch below in QEMU will effectively queue the injected queue
keycode before the 0x55 that self-test returns. The command queue is
shared with the keyboard and the i8042 so if the keyboard is active, you
may get keyboard data before getting the command responses.
>> 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.
>
> Are you able to reproduce the problem under QEMU?
I can with the following patch. It's very hard to get the right timing
manually because IO writes are much faster in QEMU. We also don't
emulate key repeat correctly in QEMU so just holding a key won't do it.
But the following patch is a reasonable approximation. kbd_put_keycode()
can happen at any time in QEMU (this is what VNC/GTK will call to inject
a keycode). This patch just makes it happen at exactly the right time
to reproduce the bug.
This replicates the same behavior in QEMU as I see on the Pixel.
(And the patch I sent fixes the problem with my hacked QEMU).
diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index 08ceb9f..bc35dd6 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -26,6 +26,7 @@
#include "hw/i386/pc.h"
#include "hw/input/ps2.h"
#include "sysemu/sysemu.h"
+#include "ui/console.h"
/* debug PC keyboard */
//#define DEBUG_KBD
@@ -267,6 +268,7 @@ static void kbd_write_command(void *opaque, hwaddr addr,
break;
case KBD_CCMD_SELF_TEST:
s->status |= KBD_STAT_SELFTEST;
+kbd_put_keycode(0x1d);
kbd_queue(s, 0x55, 0);
break;
case KBD_CCMD_KBD_TEST:
Regards,
Anthony Liguori
> I'd guess someone on the coreboot list could describe how to reflash
> the pixel. I don't own one myself.
>
> -Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
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 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 wrote:
>
>> stefan, how do we fix this?
>>
>> On Wed, Apr 24, 2013 at 6:36 PM, Anthony Liguori
>> 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"
>> > To: ""
>> > Cc: "Kevin O'Connor" , "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
>> > ---
>> > 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; 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
Re: [SeaBIOS] [Qemu-devel] [Qemu PATCH v2] add a boot option to do strict boot
Eric Blake 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 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 > 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 > > > > -- > 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 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 link'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_1234&DEV_&SUBSYS_11001AF4&REV_00\3&13C0B0C5&0&10 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 11:25 AM, Anthony Liguori wrote: 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? Sad, I think I might have a bad kernel module... Regards, Anthony Liguori 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] [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/19/2011 01:40 PM, Richard W.M. Jones wrote: On Mon, Dec 19, 2011 at 07:16:02PM +, Daniel P. Berrange wrote: On Mon, Dec 19, 2011 at 07:04:54PM +, Richard W.M. Jones wrote: On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote: I would like to point out that August -> October is a pretty long time period for a regression like this to exist. I think that really indicates that the primary problem is testing, not frequency of SeaBIOS updates. Fair point. My understanding is we're going to switch to having qemu.git in Fedora Rawhide, which means that libguestfs will always be testing the 'perfect storm' of qemu + kernel + glibc from git (once glibc get their act together anyhow, just qemu + kernel at first). We usually do a build and a comprehensive test at least once a week, often a few times a week, so we would have picked this up much sooner. That wouldn't actually catch this problem, because when we build QEMU in Fedora, we never use the SeaBIOS that QEMU includes in GIT. Fedora always ships the newest SeaBIOS release available from upstream, regardless of what QEMU includes. Ah yes indeed, I forgot about this. Nevertheless, it'll at least improve other aspects of our qemu testing :-) In reply to Anthony: the reason Fedora does this is because binary blobs aren't permitted, no matter what the origin. We have to build SeaBIOS from source, and the choice is made to build from the upstream SeaBIOS source, not from the source release indirectly pointed to by qemu. FWIW, we ship SeaBIOS source directly in our release tarballs. There's nothing indirect about it. Fedora could have a seabios-qemu RPM that was built from the qemu SRPM. Since it ultimately is going to live in /usr/share/qemu, that seems like a nicer thing to do AFAICT. You could have an alternatives mechanism if people really wanted to use upstream SeaBIOS... Regards, Anthony Liguori Rich. ___ 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/19/2011 01:19 PM, Daniel P. Berrange wrote: On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote: I would like to point out that August -> October is a pretty long time period for a regression like this to exist. I think that really indicates that the primary problem is testing, not frequency of SeaBIOS updates. One complication is that alot of us are not necessarily testing the SeaBIOS that is in QEMU GIT. Fedora rawhide includes qemu-kvm.git snapshots which are updated fairly frequently, but we don't use the SeaBIOS QEMU includes. Instead Fedora includes the latest SeaBIOS upstream release. I understand why Debian and Fedora do this but it is unfortunate from a QA perspective. Fedora is on a different release schedule than QEMU, so it's easy for it to do an "upstream freeze", and grab the latest SeaBIOS release and QEMU release. But we don't treat SeaBIOS as a separate package supporting arbitrary combinations of SeaBIOS and QEMU. Regards, Anthony Liguori So Fedora 16/rawhide users would never have seen this particular bug for longer than a couple of weeks until the fixed SeaBIOS arrived. Regards, Daniel ___ 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/19/2011 11:43 AM, Daniel P. Berrange wrote: On Mon, Dec 19, 2011 at 11:34:13AM -0600, Anthony Liguori wrote: On 12/19/2011 04:31 AM, Daniel P. Berrange wrote: Sigh, we really need to be better about updating SeaBIOS in QEMU before release. We had plenty of time to pull in a newer SeaBIOS before 1.0 that would have fixed this :-( 1.6.3.1 was released on Nov 24th, which was actually after the soft feature freeze. We could have pulled 1.6.3 which was Oct 4th but updating the BIOS always results in some interesting things happening so it's not something I like to do unless we have to. I'd rather have known that this functionality broken before that commit event went in to begin with than allowing it to remain broken until we happened to update past the bug. We've had multiple releases now where functionality is broken due to QEMU shipping with an older SeaBIOS release than is available upstream. I think the real issue here is testing. -nodefconfig -nodefaults is used by both libguestfs and libvirt but I'd wager to say that almost noone tests it in QEMU. I had actually discovered& pointed out this flaw on qemu-devel back in September, and Kevin had the seabios fix by Oct http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00029.html I hadn't raised it again, because I had mistakenly assumed QEMU will automatically pull in the newer SeaBios release before 1.0 came out. I could have more aggresively bugged people on qemu-devel to update SeaBios, but given your point above about not wanting to rebase Seabios its not clear that would have helped sort this out before 1.0 We really need to update SeaBIOS whenever there is a bug that we know requires an update. Things breakdown because of one or more of the following reasons: 1) User submits a patch to seabios@, Kevin applies it. But that doesn't necessarily trigger anything happening in QEMU. Ideally, the above mentioned user would submit a submodule update once (1) happens. 2) Kevin fixes something on his own or someone else changes something in the broader SeaBIOS community. That may not even be visible in QEMU. Syncing right before release isn't a good strategy either because that means we're pulling in something that hasn't been tested extensively at the very tail end of our release cycle. I would like to point out that August -> October is a pretty long time period for a regression like this to exist. I think that really indicates that the primary problem is testing, not frequency of SeaBIOS updates. Regards, Anthony Liguori Regards, Daniel ___ 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/19/2011 04:31 AM, Daniel P. Berrange wrote: On Sat, Dec 17, 2011 at 11:49:56AM -0500, Kevin O'Connor wrote: On Sat, Dec 17, 2011 at 10:24:07AM -0600, Anthony Liguori wrote: 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 Date: Wed Aug 10 17:34:13 2011 +0200 seabios: update to master This looks like the same issue reported at: http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00029.html The SeaBIOS fix for this was in rel-1.6.3.1 - but that didn't make QEmu 1.0. Does the problem go away if you upgrade to the newer SeaBIOS version? Sigh, we really need to be better about updating SeaBIOS in QEMU before release. We had plenty of time to pull in a newer SeaBIOS before 1.0 that would have fixed this :-( 1.6.3.1 was released on Nov 24th, which was actually after the soft feature freeze. We could have pulled 1.6.3 which was Oct 4th but updating the BIOS always results in some interesting things happening so it's not something I like to do unless we have to. I'd rather have known that this functionality broken before that commit event went in to begin with than allowing it to remain broken until we happened to update past the bug. We've had multiple releases now where functionality is broken due to QEMU shipping with an older SeaBIOS release than is available upstream. I think the real issue here is testing. -nodefconfig -nodefaults is used by both libguestfs and libvirt but I'd wager to say that almost noone tests it in QEMU. I thought about it quite a bit and what I came to was that we need to do a better job of making it easy to test these things, hence qemu-test that I just announced. Regards, Anthony Liguori Regards, Daniel ___ 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 10:49 AM, Kevin O'Connor wrote: On Sat, Dec 17, 2011 at 10:24:07AM -0600, Anthony Liguori wrote: 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 Date: Wed Aug 10 17:34:13 2011 +0200 seabios: update to master This looks like the same issue reported at: http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00029.html The SeaBIOS fix for this was in rel-1.6.3.1 - but that didn't make QEmu 1.0. Does the problem go away if you upgrade to the newer SeaBIOS version? Er, I can't actually build SeaBIOS anymore... The version of LD on this system does not properly handle alignments. As a result, this project can not be built. The problem may be the result of this LD bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=12726 Please update to a working version of binutils and retry. Makefile:75: *** "Please upgrade GCC and/or binutils". Stop. Let me find a box with a newer binutils... Regards, Anthony Liguori -Kevin ___ 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 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 :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
Re: [SeaBIOS] [Qemu-devel] Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends
On 10/10/2011 12:08 PM, Daniel P. Berrange wrote: I've been investigating where time disappears to when booting Linux guests. Initially I enabled DEBUG_BIOS in QEMU's hw/pc.c, and then hacked it so that it could print a timestamp before each new line of debug output. The problem with that is that it slowed down startup, so the timings I was examining all changed. What I really wanted was to use QEMU's trace infrastructure with a simple SystemTAP script. This is easy enough in the QEMU layer, but I also need to see where time goes to inside the various BIOS functions, and the options ROMs such as LinuxBoot. So I came up with a small hack to insert "probes" into SeaBios and LinuxBoot, which trigger a special IO port (0x404), which then cause QEMU to emit a trace event. The implementation is really very crude and does not allow any arguments to be passed each probes, but since all I care about is timing information, it is good enough for my needs. I'm not really expecting these patches to be merged into QEMU/SeaBios since they're just a crude hack& I don't have time to write something better. I figure they might be useful for someone else though... With the attached patches applied to QEMU and SeaBios, the attached systemtap script can be used to debug timings in QEMU startup. For example, one execution of QEMU produced the following log: $ stap qemu-timing.stp 0.000 Start 0.036 Run 0.038 BIOS post 0.180 BIOS int 19 0.181 BIOS boot OS 0.181 LinuxBoot copy kernel 1.371 LinuxBoot copy initrd Yeah, there was a thread a bit ago about the performance of the interface to read the kernel/initrd. I think at it was using single byte access instructions and there were patches to use string accessors instead? I can't remember where that threaded ended up. CC'ing Gleb and Alex who may recall more. Regards, Anthony Liguori 1.616 LinuxBoot boot OS 2.489 Shutdown request 2.490 Stop showing that LinuxBoot is responsible for by far the most execution time (~1500ms), in my test which runs for 2500ms in total. Regards, Daniel ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] Time to cut a new release?
On 08/04/2011 01:49 PM, Gerd Hoffmann wrote: Hi, A bunch of new stuff has been added to master since the last version, time to release a new one? Especially I'd like to see qemu get a seabios update, and anthony prefers a release instead of a git snapshot for that. What's left in order to enable CONFIG_AHCI by default too? I'd really prefer not to carry a custom config for QEMU if it's possible. Maybe this is a good time to coordinate a release around the next QEMU release too. I'm guessing that October would be a pretty good time to freeze on a new SeaBIOS so if there was an October release, that would work very well for us. Regards, Anthony Liguori cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Support more than one vga card
On 05/04/2011 11:22 AM, Glauber Costa wrote: On Tue, 2011-05-03 at 20:51 -0400, Kevin O'Connor wrote: On Tue, May 03, 2011 at 09:41:48PM -0300, Glauber Costa wrote: On Tue, 2011-05-03 at 19:58 -0400, Kevin O'Connor wrote: My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed. My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly. how's that different in pci vs vgaroms/ ? "Could cause a real machine to not boot" is true regardless. I don't understand your question. For regular PCI devices every option rom should be run, regardles of how many devices are in the system. VGA option roms are special though - my understanding is exactly one VGA device should have its option rom executed. let me rephrase then: what if you have n vga option roms under fw_cfg's vgaroms/ ? Would you execute only one of them? I'm a bit confused. With sgabios, how is it normally loaded on bare metal? I thought it's often just flashed in a dummy PCI device, make part of the BIOS image with a bios editor, or even loaded as part of a NICs firmware. Is it critical that this is loaded as a VGA rom verses a normal option ROM? The only difference with VGA roms are that they are loaded slightly earlier in the process. You shouldn't lose a lot loading them with normal PCI option roms. Regards, Anthony Liguori ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Support more than one vga card
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote: Glauber Costa wrote: It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU. Can't SGAbios be loaded as an option rom without this change? But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery. But supporting multiple VGA cards is something we want anyway since I think Spice uses this to have multiple heads. Gerd? Regards, Anthony Liguori Sebastian ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
