[PATCH] tools/kconfig/{m,n}conf.c: Fix typo »This interface let*s*«
by Paul Menzel
Date: Mon, 4 Mar 2013 12:56:56 +0100
When Kconfig was introduced in SeaBIOS with
commit a4c5daf0e2545361fadcad3015e10f8b23e53926
Author: Kevin O'Connor <kevin(a)koconnor.net>
Date: Mon Jan 24 22:13:58 2011 -0500
Initial commit of Kconfig build tool.
this typo was copied from Kconfig in Linux v2.6.38-rc2. In the meantime
Linux commit »kconfig: nconf: rewrite help texts« (0b616500) [1] rewrote
the texts for `nconf.c` – which might be ported too to SeaBIOS – and the
typo was fixed there. But it is still present in `mconf.c` as of Linux
3.8.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id...
---
tools/kconfig/mconf.c | 2 +-
tools/kconfig/nconf.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/kconfig/mconf.c b/tools/kconfig/mconf.c
index d433c7a..2a24c42 100644
--- a/tools/kconfig/mconf.c
+++ b/tools/kconfig/mconf.c
@@ -25,7 +25,7 @@
static const char mconf_readme[] = N_(
"Overview\n"
"--------\n"
-"This interface let you select features and parameters for the build.\n"
+"This interface lets you select features and parameters for the build.\n"
"Features can either be built-in, modularized, or ignored. Parameters\n"
"must be entered in as decimal or hexadecimal numbers or text.\n"
"\n"
diff --git a/tools/kconfig/nconf.c b/tools/kconfig/nconf.c
index db56377..bb797c9 100644
--- a/tools/kconfig/nconf.c
+++ b/tools/kconfig/nconf.c
@@ -15,7 +15,7 @@
static const char nconf_readme[] = N_(
"Overview\n"
"--------\n"
-"This interface let you select features and parameters for the build.\n"
+"This interface lets you select features and parameters for the build.\n"
"Features can either be built-in, modularized, or ignored. Parameters\n"
"must be entered in as decimal or hexadecimal numbers or text.\n"
"\n"
--
1.7.10.4
5 years, 10 months
[PATCHv2] pci: load memory window setup from host
by Michael S. Tsirkin
Load memory window setup for pci from host.
This makes it possible for host to make sure
setup matches hardware exactly: especially important
for when ACPI tables are loaded from host.
This will also make it easier to add more chipsets
down the road.
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
---
Changes from v1:
- fix bug in 64 bit range check
- address Kevin's comments:
move file load into pciinit.c
dont reorder initialization
sizeof style fix
src/pciinit.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 75 insertions(+), 16 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index bb9355f..a4a5bf5 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -13,6 +13,7 @@
#include "config.h" // CONFIG_*
#include "memmap.h" // add_e820
#include "paravirt.h" // RamSize
+#include "byteorder.h" // le64_to_cpu
#include "dev-q35.h"
/* PM Timer ticks per second (HZ) */
@@ -61,6 +62,13 @@ struct pci_bus {
struct pci_device *bus_dev;
};
+struct pci_mem {
+ u64 start32;
+ u64 end32;
+ u64 start64;
+ u64 end64;
+};
+
static u32 pci_bar(struct pci_device *pci, int region_num)
{
if (region_num != PCI_ROM_SLOT) {
@@ -361,6 +369,8 @@ static void pci_enable_default_vga(void)
void i440fx_mem_addr_setup(struct pci_device *dev, void *arg)
{
+ if (arg)
+ /* use supplied memory */;
if (RamSize <= 0x80000000)
pcimem_start = 0x80000000;
else if (RamSize <= 0xc0000000)
@@ -383,8 +393,9 @@ void mch_mem_addr_setup(struct pci_device *dev, void *arg)
pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, lower);
add_e820(addr, size, E820_RESERVED);
- /* setup pci i/o window (above mmconfig) */
- pcimem_start = addr + size;
+ /* unless done already, setup pci i/o window (above mmconfig) */
+ if (!arg)
+ pcimem_start = addr + size;
pci_slot_get_irq = mch_pci_slot_get_irq;
}
@@ -397,11 +408,11 @@ static const struct pci_device_id pci_platform_tbl[] = {
PCI_DEVICE_END
};
-static void pci_bios_init_platform(void)
+static void pci_bios_init_platform(struct pci_mem *mem)
{
struct pci_device *pci;
foreachpci(pci) {
- pci_init_device(pci_platform_tbl, pci, NULL);
+ pci_init_device(pci_platform_tbl, pci, mem);
}
}
@@ -762,10 +773,14 @@ static void pci_region_map_entries(struct pci_bus *busses, struct pci_region *r)
}
}
-static void pci_bios_map_devices(struct pci_bus *busses)
+static void pci_bios_map_devices(struct pci_bus *busses, struct pci_mem *mem)
{
if (pci_bios_init_root_regions(busses)) {
struct pci_region r64_mem, r64_pref;
+
+ if (mem && mem->start64 >= mem->end64)
+ panic("PCI: out of 32bit address space\n");
+
r64_mem.list = NULL;
r64_pref.list = NULL;
pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_MEM],
@@ -781,14 +796,27 @@ static void pci_bios_map_devices(struct pci_bus *busses)
u64 align_mem = pci_region_align(&r64_mem);
u64 align_pref = pci_region_align(&r64_pref);
- r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem);
- r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref);
- pcimem64_start = r64_mem.base;
- pcimem64_end = r64_pref.base + sum_pref;
+ if (mem) {
+ /*
+ * Non prefetcheable memory at start of the window,
+ * prefetcheable memory at the end.
+ * This way OS has the maximum flexibility for
+ * allocating the rest of the memory.
+ */
+ r64_mem.base = ALIGN(mem->start64, align_mem);
+ r64_pref.base = ALIGN_DOWN(mem->end64 - sum_pref + 1, align_pref);
+ if (sum_pref && r64_pref.base < r64_mem.base + sum_mem)
+ panic("PCI: out of 64bit address space\n");
+ } else {
+ r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem);
+ r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref);
+ pcimem64_start = r64_mem.base;
+ pcimem64_end = r64_pref.base + sum_pref;
+ }
pci_region_map_entries(busses, &r64_mem);
pci_region_map_entries(busses, &r64_pref);
- } else {
+ } else if (!mem) {
// no bars mapped high -> drop 64bit window (see dsdt)
pcimem64_start = 0;
}
@@ -801,11 +829,28 @@ static void pci_bios_map_devices(struct pci_bus *busses)
}
}
+static
+struct pci_mem *pci_mem_get(void)
+{
+ int psize;
+ struct pci_mem *mem = romfile_loadfile("etc/pci-info", &psize);
+ if (!mem)
+ return NULL;
+ if (psize < sizeof(*mem)) {
+ free(mem);
+ return NULL;
+ }
+ mem->start32 = le64_to_cpu(mem->start32);
+ mem->end32 = le64_to_cpu(mem->end32);
+ mem->start64 = le64_to_cpu(mem->start64);
+ mem->end64 = le64_to_cpu(mem->end64);
+ return mem;
+}
+
/****************************************************************
* Main setup code
****************************************************************/
-
void
pci_setup(void)
{
@@ -823,25 +868,39 @@ pci_setup(void)
dprintf(1, "=== PCI device probing ===\n");
pci_probe_devices();
- pcimem_start = RamSize;
- pci_bios_init_platform();
+ struct pci_mem *mem = pci_mem_get();
+
+ if (mem) {
+ pcimem_start = mem->start32;
+ pcimem_end = mem->end32;
+ pcimem64_start = mem->start64;
+ pcimem64_end = mem->end64;
+ } else {
+ pcimem_start = RamSize;
+ }
+
+ pci_bios_init_platform(mem);
dprintf(1, "=== PCI new allocation pass #1 ===\n");
struct pci_bus *busses = malloc_tmp(sizeof(*busses) * (MaxPCIBus + 1));
if (!busses) {
warn_noalloc();
- return;
+ goto done;
}
memset(busses, 0, sizeof(*busses) * (MaxPCIBus + 1));
if (pci_bios_check_devices(busses))
- return;
+ goto done;
dprintf(1, "=== PCI new allocation pass #2 ===\n");
- pci_bios_map_devices(busses);
+ pci_bios_map_devices(busses, mem);
pci_bios_init_devices();
free(busses);
pci_enable_default_vga();
+
+done:
+ if (mem)
+ free(mem);
}
--
MST
6 years, 1 month
[PATCH v2 00/19] SeaBIOS as Compatibility Support Module for UEFI/OVMF
by David Woodhouse
Changes from v1:
- Make CONFIG_CSM a top-level build target in parallel with COREBOOT/QEMU.
- More Kconfig cleanup.
- Add generic find_pmtimer() function to find the pmtimer from ACPI tables.
- Make Xen and coreboot builds both use find_pmtimer().
- Merge E820 table one entry at a time instead of wholesale copy.
- Add pic_save_mask() and pic_restore_mask() functions.
- Less intrusive size reduction for handle_post().
- Various other cleanups.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
6 years, 1 month
[PULL 0/2] chardev: fix "info chardev" output
by Gerd Hoffmann
Hi,
Tiny series, first reverting the broken patch from Lei Li,
then fixing it for real.
please pull,
Gerd
The following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29:
Remove Sun4c, Sun4d and a few CPUs (2013-05-26 11:37:58 +0000)
are available in the git repository at:
git://git.kraxel.org/qemu chardev.6
for you to fetch changes up to 60d95386abf1f5f37ded6a812d12ac458df2491b:
chardev: fix "info chardev" output (2013-05-27 12:47:28 +0200)
----------------------------------------------------------------
Gerd Hoffmann (2):
Revert "chardev: Get filename for new qapi backend"
chardev: fix "info chardev" output
qemu-char.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
6 years, 2 months
[PULL 0/2] update seabios to release 1.7.2.2
by Gerd Hoffmann
Hi,
This pull updates seabios to the 1.7.2.2 release tagged yesterday,
bringing some fixes which unfortunaly missed the qemu 1.5 boat.
please pull,
Gerd
The following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29:
Remove Sun4c, Sun4d and a few CPUs (2013-05-26 11:37:58 +0000)
are available in the git repository at:
git://git.kraxel.org/qemu seabios-1.7.2.2
for you to fetch changes up to 6683d7bc2759e9da8b5c4907a9de85d500933ffb:
update seabios to release 1.7.2.2 (2013-05-28 12:19:02 +0200)
----------------------------------------------------------------
Gerd Hoffmann (2):
Revert "roms: switch oldnoconfig to olddefconfig"
update seabios to release 1.7.2.2
pc-bios/bios.bin | Bin 131072 -> 131072 bytes
roms/configure-seabios.sh | 2 +-
roms/seabios | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
6 years, 2 months
[PATCH v3] config: allow DEBUG_IO for !QEMU
by Gerd Hoffmann
Allow selecting DEBUG_IO for non-qemu configurations,
which is useful when running coreboot+seabios on qemu.
[ v2: QEMU_HARDWARE is even better as DEBUG_IO default value ]
[ v3: make QEMU_HARDWARE usage consistent with other config
options, fix spellings in commit message ]
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
src/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/Kconfig b/src/Kconfig
index 3c80132..5882d11 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -425,7 +425,7 @@ menu "Debugging"
Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8.
config DEBUG_IO
- depends on QEMU && DEBUG_LEVEL != 0
+ depends on QEMU_HARDWARE && DEBUG_LEVEL != 0
bool "Special IO port debugging"
default y
help
--
1.7.9.7
6 years, 2 months
[PATCH RFC 00/13] qemu: generate acpi tables for the guest
by Michael S. Tsirkin
This patchset moves all generation of ACPI tables
from guest BIOS to the hypervisor.
Although ACPI tables come from a system BIOS on real hw,
it makes sense that the ACPI tables are coupled with the
virtual machine, since they have to abstract the x86 machine to
the OS's.
Several future developments that this will enable:
- make it easier to use alternative firmware:
any firmware can just load the ACPI tables from QEMU.
case in point OVMF.
- make it easier to add more chipsets without bumping
into fw_cfg boundaries.
- describe a complex configuration
e.g. a bridged PCI topology to enable
acpi hotplug of devices behind a PCI bridge,
or for multi-root topology.
If you look at the actual code:
i386: imports ACPI table generation code from seabios
you will see that it's more complex than it
needs to be, with lots of low level casts
and similar tricks.
There's also a bit of duplication where we
already declare similar acpi structures in qemu.
This is the result of code being a direct port from seabios.
Laszlo's patch (build ACPI MADT (APIC) for fw_cfg)
shows how this will be cleaned up by follow-up work.
I think it's best to do it in this order: port
code directly, and apply cleanups and reduce duplication
that results, on top.
This way it's much easier to see that we don't introduce
regressions.
In particular, for a simple VM with piix,
I booted a guest on qemu with and without the
change, and verified that ACPI tables are
unchanged except for trivial pointer address changes.
Such binary compatibility makes it easier to be
confident that this change won't break things.
So the idea is Laszlo's patchset (patches 2-7) will be rebased on top of
this patchset, this way we'll get small cleanup changes, where each step
is easy to verify as not changing anything from Guest POV.
One issue this patchset creates is cross-version migration.
Specifically migration to qemu 1.5 will not work
if it happens while bios is accessing fw_cfg when we
migrate.
This is a general problem of the fw_cfg implementation,
I plan to extend fw_cfg implementation to address this.
I plan to test q35 and numa setups before I submit
this for inclusion, in a similar way.
git trees, for those interested in testing this:
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi
git://git.kernel.org/pub/scm/virt/kvm/mst/seabios.git acpi
bios patchset will be posted tomorrow (need to clean up
the commit log a bit).
Laszlo Ersek (1):
refer to FWCfgState explicitly
Michael S. Tsirkin (12):
apic: rename apic specific bitopts
hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h
fw_cfg: move typedef to qemu/typedefs.h
i386: add ACPI table files from seabios
acpi: add rules to compile ASL source
acpi: pre-compiled ASL files
range: add Range structure
i386: add bios linker/loader
i386: generate pc guest info
pc: pass PCI hole ranges to Guests
i386: ACPI table generation code from seabios
pc: reuse guest info for legacy fw cfg
configure | 9 +-
hw/acpi/ich9.c | 7 +-
hw/acpi/piix4.c | 44 +-
hw/core/loader.c | 2 +-
hw/i386/Makefile.objs | 27 +
hw/i386/acpi-build.c | 685 ++++
hw/i386/acpi-dsdt-cpu-hotplug.dsl | 93 +
hw/i386/acpi-dsdt-dbug.dsl | 41 +
hw/i386/acpi-dsdt-hpet.dsl | 51 +
hw/i386/acpi-dsdt-isa.dsl | 117 +
hw/i386/acpi-dsdt-pci-crs.dsl | 105 +
hw/i386/acpi-dsdt.dsl | 343 ++
hw/i386/acpi-dsdt.hex.generated | 4409 ++++++++++++++++++++
hw/i386/bios-linker-loader.c | 155 +
hw/i386/multiboot.c | 2 +-
hw/i386/multiboot.h | 4 +-
hw/i386/pc.c | 159 +-
hw/i386/pc_piix.c | 28 +-
hw/i386/pc_q35.c | 14 +-
hw/i386/q35-acpi-dsdt.dsl | 452 +++
hw/i386/q35-acpi-dsdt.hex.generated | 7346 ++++++++++++++++++++++++++++++++++
hw/i386/ssdt-misc.dsl | 73 +
hw/i386/ssdt-misc.hex.generated | 190 +
hw/i386/ssdt-pcihp.dsl | 51 +
hw/i386/ssdt-pcihp.hex.generated | 108 +
hw/i386/ssdt-proc.dsl | 63 +
hw/i386/ssdt-proc.hex.generated | 134 +
hw/intc/apic.c | 42 +-
hw/isa/lpc_ich9.c | 11 +-
hw/mips/mips_malta.c | 2 +-
hw/pci-host/q35.c | 5 +
hw/sparc/sun4m.c | 6 +-
hw/sparc64/sun4u.c | 2 +-
include/hw/acpi/ich9.h | 2 +-
include/hw/i386/acpi-build.h | 9 +
include/hw/i386/apic.h | 2 +
include/hw/i386/bios-linker-loader.h | 26 +
include/hw/i386/ich9.h | 3 +-
include/hw/i386/pc.h | 67 +-
include/hw/loader.h | 3 +-
include/hw/nvram/fw_cfg.h | 2 +-
include/hw/pci-host/q35.h | 2 +
include/qemu/range.h | 22 +
include/qemu/typedefs.h | 2 +
scripts/acpi_extract.py | 362 ++
scripts/acpi_extract_preprocess.py | 52 +
scripts/update-acpi.sh | 4 +
47 files changed, 15248 insertions(+), 90 deletions(-)
create mode 100644 hw/i386/acpi-build.c
create mode 100644 hw/i386/acpi-dsdt-cpu-hotplug.dsl
create mode 100644 hw/i386/acpi-dsdt-dbug.dsl
create mode 100644 hw/i386/acpi-dsdt-hpet.dsl
create mode 100644 hw/i386/acpi-dsdt-isa.dsl
create mode 100644 hw/i386/acpi-dsdt-pci-crs.dsl
create mode 100644 hw/i386/acpi-dsdt.dsl
create mode 100644 hw/i386/acpi-dsdt.hex.generated
create mode 100644 hw/i386/bios-linker-loader.c
create mode 100644 hw/i386/q35-acpi-dsdt.dsl
create mode 100644 hw/i386/q35-acpi-dsdt.hex.generated
create mode 100644 hw/i386/ssdt-misc.dsl
create mode 100644 hw/i386/ssdt-misc.hex.generated
create mode 100644 hw/i386/ssdt-pcihp.dsl
create mode 100644 hw/i386/ssdt-pcihp.hex.generated
create mode 100644 hw/i386/ssdt-proc.dsl
create mode 100644 hw/i386/ssdt-proc.hex.generated
create mode 100644 include/hw/i386/acpi-build.h
create mode 100644 include/hw/i386/bios-linker-loader.h
create mode 100755 scripts/acpi_extract.py
create mode 100755 scripts/acpi_extract_preprocess.py
create mode 100644 scripts/update-acpi.sh
--
MST
6 years, 2 months
[QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
by Amos Kong
Recent virtio refactoring in QEMU made virtio-bus become the parent bus
of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
typename will be added to fw_dev_path by default, the new fw_dev_path
could not be identified by seabios. It causes that bootindex parameter
of scsi device doesn't work.
This patch implements get_fw_dev_path() in BusClass, it will be called
if bus doesn't implement the method, tyename will be added to
fw_dev_path. If the implemented method returns NULL, nothing will be
added to fw_dev_path.
It also implements virtio_bus_get_fw_dev_path() to return NULL. Then
QEMU will still pass original style of fw_dev_path to seabios.
Signed-off-by: Amos Kong <akong(a)redhat.com>
--
v2: only add nothing to fw_dev_path when get_fw_dev_path() is
implemented and returns NULL. then it will not effect other devices
don't have get_fw_dev_path() implementation.
v3: implement default get_fw_dev_path() in BusClass
---
hw/core/qdev.c | 10 +++++++++-
hw/virtio/virtio-bus.c | 6 ++++++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..9190a7e 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
l += snprintf(p + l, size - l, "%s", d);
g_free(d);
} else {
- l += snprintf(p + l, size - l, "%s", object_get_typename(OBJECT(dev)));
+ return l;
}
}
l += snprintf(p + l , size - l, "/");
@@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj)
QTAILQ_INIT(&bus->children);
}
+static char *default_bus_get_fw_dev_path(DeviceState *dev)
+{
+ return g_strdup(object_get_typename(OBJECT(dev)));
+}
+
static void bus_class_init(ObjectClass *class, void *data)
{
+ BusClass *bc = BUS_CLASS(class);
+
class->unparent = bus_unparent;
+ bc->get_fw_dev_path = default_bus_get_fw_dev_path;
}
static void qbus_finalize(Object *obj)
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index ea2e11a..6849a01 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState *dev)
return qdev_get_dev_path(proxy);
}
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev)
+{
+ return NULL;
+}
+
static void virtio_bus_class_init(ObjectClass *klass, void *data)
{
BusClass *bus_class = BUS_CLASS(klass);
bus_class->get_dev_path = virtio_bus_get_dev_path;
+ bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path;
}
static const TypeInfo virtio_bus_info = {
--
1.8.1.4
6 years, 2 months
Re: [SeaBIOS] KVM call agenda for 2013-05-28
by Laszlo Ersek
On 05/31/13 09:09, Jordan Justen wrote:
> Why is updating the ACPI tables in seabios viewed as such a burden?
> Either qemu does it, or seabios... (And, OVMF too, but I don't think
> you guys are concerned with that. :)
I am :)
> On the flip side, why is moving the ACPI tables to QEMU such an issue?
> It seems like Xen and virtualbox both already do this. Why is running
> iasl not an issue for them?
I think something was mentioned about iasl having problems on BE
machines? I could be easily wrong but I *guess* qemu's hosts x targets
(emulate what on what) set is a proper superset of xen's and
virtualbox's. Presumably if you want to run an x86 guest on a MIPS host,
and also want to build qemu on the same MIPS (or SPARC) host, you'd have
to run iasl there too.
> Maybe we are doing lots of things horribly wrong in our OVMF ACPI
> tables :)
Impossible. :)
In earnest, I think what we have now is (mostly) correct, just not
extensive / flexible enough. No support for PCI hotplug or CPU hotplug,
none for S3 (although all of these tie into UEFI deeply), no MTRR setup,
no MPTABLE; let alone a non-PIIX chipset. (Well maybe I shouldn't lump
these under the "ACPI umbrella".)
> but I haven't seen it as much of a burden. (Of course,
> Laszlo has helped out with many of the ACPI changes in OVMF, so his
> opinion should be taken into consideration too. :)
It hasn't been a "burden" in the sense of me not liking the activity; I
actually like fiddling with knobs. It has certainly been extra work to
bring OVMF's ACPI tables closer to SeaBIOS's functionality / flexibility
(and we still lag behind it quite.).
Due to licensing differences I can't just port code from SeaBIOS to OVMF
(and I never have without explicit permission), so it's been a lot of
back and forth with acpidump / iasl -d in guests (massage OVMF, boot
guest, check guest dmesg / lspci, dump tables, compare, repeat), brain
picking colleagues, the ACPI and PIIX specs and so on. I have a page on
the RH intranet dedicated to this. When something around these parts is
being changed (or looks like it could be changed) in SeaBIOS, or between
qemu and SeaBIOS, I always must be alert and consider reimplementing it
in, or porting it with permission to, OVMF. (Most recent example:
pvpanic device -- currently only in SeaBIOS.)
It worries me that if I slack off, or am busy with something else, or
simply don't notice, then the gap will widen again. I appreciate
learning a bunch about ACPI, and don't mind the days of work that went
into some of my simple-looking ACPI patches for OVMF, but had the tables
come from a common (programmatic) source, none of this would have been
an issue, and I wouldn't have felt even occasionally that ACPI patches
for OVMF were both duplicate work *and* futile (considering how much
ahead SeaBIOS was).
I don't mind reimplementing stuff, or porting it with permission, going
forward, but the sophisticated parts in SeaBIOS are a hard nut. For
example I'll never be able to auto-extract offsets from generated AML
and patch the AML using those offsets; the edk2 build tools (a project
separate from edk2) don't support this, and it takes several months to
get a thing as simple as gcc-47 build flags into edk2-buildtools.
Instead I have to write template ASL, compile it to AML, hexdump the
result, verify it against the AML grammar in the ACPI spec (offsets
aren't obvious, BytePrefix and friends are a joy), define & initialize a
packed struct or array in OVMF, and patch the template AML using fixed
field names or array subscripts. Workable, but dog slow. If the ACPI
payload came from up above, we might be as well provided with a list of
(canonical name, offset, size) triplets, and could perhaps blindly patch
the contents. (Not unlike Michael's linker code for connecting tables
into a hierarchy.)
AFAIK most recently iasl got built-in support for offset extraction (and
in the process the current SeaBIOS build method was broken...), so that
part might get easier in the future.
Oh well it's Friday, sorry about this rant! :) I'll happily do what I
can in the current status quo, but frequently, it won't amount to much.
Thanks,
Laszlo
6 years, 2 months
KVM call agenda for 2013-05-28
by Michael S. Tsirkin
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating acpi tables
- Switching the call to a bi-weekly schedule
Please, send any topic that you are interested in covering.
Thanks, MST
--
MST
6 years, 2 months
