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

[Anthony Liguori <anthony@codemonkey.ws>]

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