David Woodhouse dwmw2@infradead.org writes:
On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote:
Internally within QEMU, this initial discussion started by saying that any ACPI generation within QEMU should happen strictly with QOM methods. This was the crux of my argument, if QOM is the only interface we need, everything is there for the firmware to do the same job that QEMU would be doing.
That's nice in theory, but I'm not sure how it works as things evolve and new things / new features get exposed. The firmware's *interpretation* of the QOM tree needs to be kept in sync with qemu.
Hm, make that: The firmwares' *interpretation*…
Let's take a specific, recent example. We fixed the PIIX4 code to actually handle the hard reset on port 0xcf9. We need to fix the ACPI tables to indicate a usable RESET_REG.
Very good example.
Normally, we try to be bug-for-bug compatible for guests such that -M pc-1.4 would behave exactly the same.
In this case, we failed to introduce a property to control this behavior like we should have. If this changes the guest ACPI tables, it definitely should definitely be set based on a property.
This is a good example of why this approach is good for QEMU, it helps us catch stuff like this.
How is that exposed in the QOM tree, and how does it all work? With qemu exposing ACPI tables in their close-to-final form, it's just fine. Boot with a recent qemu and it's all nice and shiny; boot with an old qemu and it doesn't reset properly.
If we did this right in QEMU, we'd have to introduce a QOM property anyway as that's how we trigger differences in machine behavior. And -M pc-1.4 ought to generate the same tables as qemu 1.4 did.
Regards,
Anthony Liguori
But if the firmware has to be updated to interpret the new feature advertised in the QOM tree and translate it into the ACPI table, then we haven't really got much of an improvement.
Please explain how this is supposed to work in *practice*.
-- dwmw2