Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

[David Woodhouse]

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.

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.

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

smime.p7s
Description: S/MIME cryptographic signature