Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anth...@codemonkey.ws wrote: Michael S. Tsirkin m...@redhat.com writes: On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: I don't think it's a good idea to move BIOS functionality in QEMU. Just to clarify: generating ACPI tables is not BIOS functionality. It ended up in seabios for historical reasons. A normal scenario for ACPI tables is that they are written in ASL and compiled with IASL. I wouldn't call this the normal scenario. Some tables are static but more tables are dynamic than you'd think. If you're a firmware engineer and you have to support dozens of platforms, it's much easier to make the tables dynamic than attempt to maintain dozens of ASL descriptions. Anthony is right. Firmware for real systems contains the tables as binary aml output from the asl compiler, but also goes through extensive hoops to tweak the ACPI information. On the other hand, real firmware doesn't have the luxury of being able to just download the ACPI tables like fw-cfg might be able to offer. I'm a little concerned that firmware might find a desire to still customize the tables, and thus the fw-cfg solution might be too restricting. It does seem to work out okay for other VMM projects though. (It does seem to be working for Xen in OVMF. But, I'm not certain how well it is working, since I don't have a Xen setup.) I mentioned in the other thread that perhaps QEMU could also consider making the ACPI code available under some 'appropriate' license, which would allow firmware writers to leverage the code directly if desired. Perhaps a dual/multi license situation for the relevant files? But, if the fw-cfg route works, then it seems the easiest option for firmware writers. -Jordan
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Jordan Justen jljus...@gmail.com writes: On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anth...@codemonkey.ws wrote: Michael S. Tsirkin m...@redhat.com writes: On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: I don't think it's a good idea to move BIOS functionality in QEMU. Just to clarify: generating ACPI tables is not BIOS functionality. It ended up in seabios for historical reasons. A normal scenario for ACPI tables is that they are written in ASL and compiled with IASL. I wouldn't call this the normal scenario. Some tables are static but more tables are dynamic than you'd think. If you're a firmware engineer and you have to support dozens of platforms, it's much easier to make the tables dynamic than attempt to maintain dozens of ASL descriptions. Anthony is right. Firmware for real systems contains the tables as binary aml output from the asl compiler, but also goes through extensive hoops to tweak the ACPI information. On the other hand, real firmware doesn't have the luxury of being able to just download the ACPI tables like fw-cfg might be able to offer. I'm a little concerned that firmware might find a desire to still customize the tables, and thus the fw-cfg solution might be too restricting. It does seem to work out okay for other VMM projects though. (It does seem to be working for Xen in OVMF. But, I'm not certain how well it is working, since I don't have a Xen setup.) I mentioned in the other thread that perhaps QEMU could also consider making the ACPI code available under some 'appropriate' license, which would allow firmware writers to leverage the code directly if desired. Perhaps a dual/multi license situation for the relevant files? Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree? I think the only solution to the licensing problem is a GPL-friendly UEFI build... Regards, Anthony Liguori But, if the fw-cfg route works, then it seems the easiest option for firmware writers. -Jordan
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Mon, Jun 3, 2013 at 4:12 PM, Anthony Liguori anth...@codemonkey.ws wrote: Jordan Justen jljus...@gmail.com writes: 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... Sounds like there is no chance for a multi-license scenario then? My idea here was that QEMU could consider what potential licensing situations alternative firmware writers might desire, and attempt to multi-license the code so it could be used as reference code for those potential consumers. I guess if that is not possible and the fw-cfg method doesn't work out, then we'll probably need to keep doing our best in re-implementing the ASL/ACPI code. OVMF is an important part of the EDK II project, and thus a viable OVMF within the EDK II tree is important. Therefore, we need BSD licensed code for the core pieces of OVMF. (Such as producing ACPI tables.) You mentioned that FatBinPkg in the EDK II tree is a particular issue for some OVMF derivatives. To solve that (as I mentioned in the other thread) I'd be willing to publish a git-submodule version of OVMF. This would also allow OVMF derived projects to include other packages. (Potentially with different source licenses.) Given that there are no FAT driver alternatives, the only purpose I could see for this anytime soon would be something that incorporates the seabios-csm. -Jordan
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
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. We don't frequently add firmware or chipsets so it seems like we're optimizing for an uncommon scenario here. Regards, Anthony Liguori By the way, on x86 we already load some ACPI tables through fw_cfg: hw/i386/pc_piix.c:pc_acpi_init(acpi-dsdt.aml); hw/i386/pc_q35.c:pc_acpi_init(q35-acpi-dsdt.aml); so putting all other tables in one place will just make things more consistent. Yes, ACPI is messy, and pc-specific, but IMO that's life: it's better to give guests as much help as we can if it's messy, not push the messiness out for guests to handle. -- MST
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
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. 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. cheers, Gerd
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On 14 May 2013 10:29, Gerd Hoffmann kra...@redhat.com wrote: Anthony wrote: 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 It depends. For ARM we insist that the user provides the device tree that corresponds to the kernel they're going to run, and then we just tweak it a bit. (For the upcoming 'mach-virt' pure-virtual hardware we're going to end up generating a device tree completely from scratch, though.) Not sure fw_cfg is particularly relevant though -- for device tree the obvious nice way to do it would be to have the device tree generating/modifying code able to walk the QOM object tree introspecting it to identify hardware presence and properties. That's probably not doable today though. (I need to look more closely at PPC device tree handling, really.) thanks -- PMM
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
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. 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. 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
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann kra...@redhat.com 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
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Michael S. Tsirkin m...@redhat.com writes: On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: I don't think it's a good idea to move BIOS functionality in QEMU. Just to clarify: generating ACPI tables is not BIOS functionality. It ended up in seabios for historical reasons. A normal scenario for ACPI tables is that they are written in ASL and compiled with IASL. I wouldn't call this the normal scenario. Some tables are static but more tables are dynamic than you'd think. If you're a firmware engineer and you have to support dozens of platforms, it's much easier to make the tables dynamic than attempt to maintain dozens of ASL descriptions. 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
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
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. 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* ... cheers, Gerd
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann kra...@redhat.com writes: Hi, and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. Huh? As far I know we generate device trees in qemu instead of expecting pseries firmware compile them from fw_cfg information. It depends on what firmware you are using. Of course. On archs which don't use device trees in the first place it doesn't make sense. We don't really generate device trees in general in QEMU. pseries does (thats why the hard libfdt dependency if you want pseries support). arm wants move into that direction too. pseries is a bad example because it's not a real hardware platform. It's emulating what PowerVM does. It's more akin to the xenpv machine than a real piece of hardware. As Peter mentioned, in an ideal world we'd generate them from the QOM graph. Sure. That should happen in the firmware and it could be enabled by adding just a couple fw_cfg commands to navigate the QOM graph (analogs to qom-list and qom-get in QMP). I don't think Peter intended to imply *that* ... Yes, this has been discussed dozens of times in the past. And as I've said in the past, generating device trees belongs in the firmware. It's a firmware/OS interface. It's not just an academic argument though. We want to expose hardware interfaces that are rich enough for firmware to do whatever it needs to do to initialize the system. There are a lot of things that are normally only visible to firmware that we don't emulate today. In exposing this information, we ought to attempt to do so in an architectural neutral way. ACPI is not architectural neutral. You could argue that that's okay because we only need to support two things: ACPI and device trees. But that's not quite right. Device trees very often have platform specific quirks so a generated device tree in common code is not going to have the right set of quirks for any given system. Having a good interface for firmware to generate ACPI tables and device trees solves this problem in a much nicer way. It enables firmware to display whatever type of tree it wants (ACPI or device tree) and also provides the flexibility to implement the necessary quirks for that platform. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Tue, May 14, 2013 at 08:34:43AM -0500, Anthony Liguori wrote: Michael S. Tsirkin m...@redhat.com writes: On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: I don't think it's a good idea to move BIOS functionality in QEMU. Just to clarify: generating ACPI tables is not BIOS functionality. It ended up in seabios for historical reasons. A normal scenario for ACPI tables is that they are written in ASL and compiled with IASL. I wouldn't call this the normal scenario. Some tables are static but more tables are dynamic than you'd think. If you're a firmware engineer and you have to support dozens of platforms, it's much easier to make the tables dynamic than attempt to maintain dozens of ASL descriptions. 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. So if you tell BIOS how to map slots to nodes it can generate SRAT. Fine but it still never needs to discover which hardware is there. 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
[Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
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|
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Michael S. Tsirkin m...@redhat.com writes: This patchset moves all generation of ACPI tables from guest BIOS to the hypervisor. Although ACPI tables come from a system BIOS on real hw, it makes sense that the ACPI tables are coupled with the virtual machine, since they have to abstract the x86 machine to the OS's. Several future developments that this will enable: - make it easier to use alternative firmware: any firmware can just load the ACPI tables from QEMU. case in point OVMF. UEFI obviously can create ACPI tables already so I don't think this is a valid advantage. You could use this argument to say that QEMU should implement int13 or int10 too... - make it easier to add more chipsets without bumping into fw_cfg boundaries. But then you're just introducing a different boundary (the ACPI tables). fw_cfg is a cross-platform interface so it makes a lot more sense to add more features to it to better enumerate the underlying platform. - describe a complex configuration e.g. a bridged PCI topology to enable acpi hotplug of devices behind a PCI bridge, or for multi-root topology. This has strong analogies to generating device trees and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. If you look at the actual code: i386: imports ACPI table generation code from seabios you will see that it's more complex than it needs to be, with lots of low level casts and similar tricks. There's also a bit of duplication where we already declare similar acpi structures in qemu. This is the result of code being a direct port from seabios. Laszlo's patch (build ACPI MADT (APIC) for fw_cfg) shows how this will be cleaned up by follow-up work. I think it's best to do it in this order: port code directly, and apply cleanups and reduce duplication that results, on top. This way it's much easier to see that we don't introduce regressions. In particular, for a simple VM with piix, I booted a guest on qemu with and without the change, and verified that ACPI tables are unchanged except for trivial pointer address changes. Such binary compatibility makes it easier to be confident that this change won't break things. So the idea is Laszlo's patchset (patches 2-7) will be rebased on top of this patchset, this way we'll get small cleanup changes, where each step is easy to verify as not changing anything from Guest POV. One issue this patchset creates is cross-version migration. Specifically migration to qemu 1.5 will not work if it happens while bios is accessing fw_cfg when we migrate. This is a general problem of the fw_cfg implementation, I plan to extend fw_cfg implementation to address this. I plan to test q35 and numa setups before I submit this for inclusion, in a similar way. git trees, for those interested in testing this: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi git://git.kernel.org/pub/scm/virt/kvm/mst/seabios.git acpi bios patchset will be posted tomorrow (need to clean up the commit log a bit). I don't think it's a good idea to move BIOS functionality in QEMU. We don't frequently add firmware or chipsets so it seems like we're optimizing for an uncommon scenario here. Regards, Anthony Liguori Laszlo Ersek (1): refer to FWCfgState explicitly Michael S. Tsirkin (12): apic: rename apic specific bitopts hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h fw_cfg: move typedef to qemu/typedefs.h i386: add ACPI table files from seabios acpi: add rules to compile ASL source acpi: pre-compiled ASL files range: add Range structure i386: add bios linker/loader i386: generate pc guest info pc: pass PCI hole ranges to Guests i386: ACPI table generation code from seabios pc: reuse guest info for legacy fw cfg configure|9 +- hw/acpi/ich9.c |7 +- hw/acpi/piix4.c | 44 +- hw/core/loader.c |2 +- hw/i386/Makefile.objs| 27 + hw/i386/acpi-build.c | 685 hw/i386/acpi-dsdt-cpu-hotplug.dsl| 93 + hw/i386/acpi-dsdt-dbug.dsl | 41 + hw/i386/acpi-dsdt-hpet.dsl | 51 + hw/i386/acpi-dsdt-isa.dsl| 117 + hw/i386/acpi-dsdt-pci-crs.dsl| 105 + hw/i386/acpi-dsdt.dsl| 343 ++ hw/i386/acpi-dsdt.hex.generated | 4409 hw/i386/bios-linker-loader.c | 155 + hw/i386/multiboot.c |2 +- hw/i386/multiboot.h |4 +- hw/i386/pc.c | 159 +- hw/i386/pc_piix.c| 28 +- hw/i386/pc_q35.c | 14 +- hw/i386/q35-acpi-dsdt.dsl| 452 +++ hw/i386/q35-acpi-dsdt.hex.generated | 7346 ++ hw/i386/ssdt-misc.dsl| 73 +
