On Mon, Jun 10, 2013 at 08:03:46PM -0500, Anthony Liguori wrote:
It is not "supported" by QEMU.
No, but I've always thought that QEMU was happy to have alternative firmware projects.
We are and we're happy to accept patches to enable things even if its proprietary. But that's all assuming we're improving hardware emulation.
What we're talking about here is doing something that's very un-hardware like.
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.
2. There's no hardware-like alternative.
A current alternative is exposing lots of PV interfaces to bios, bios builds up ACPI tables based on them. All of this code is in practice PC only, if we ever attempt to generalize we'll see how the interfaces are not a good match. They are still PV, poorly documented and it's very hard for bios not to make any assumptions about them. When it does, result is a very obscure breakage.
Yes, building tables in bios means QEMU code is simpler but we double the amount of interfaces that we need to get right: QEMU-BIOS + BIOS-OS
Yes it's "not QEMU code" but it's seen as a single package by users and it does not really matter - excellent hardware with lousy firmware is useless.