Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

[Igor Mammedov]

On Wed, 14 Oct 2015 13:47:32 -0300
Eduardo Habkost <address@hidden> wrote:

> On Wed, Oct 14, 2015 at 10:45:00AM +0200, Igor Mammedov wrote:
> > On Tue, 13 Oct 2015 16:10:03 -0300
> > Eduardo Habkost <address@hidden> wrote:
> > 
> > > On Sat, Oct 10, 2015 at 12:00:16AM -0400, Gabriel L. Somlo wrote:
> > > > On Thu, Oct 01, 2015 at 01:33:50PM +0200, Igor Mammedov wrote:
> [...]
> > > > > > >> +    if (!pcmc->acpi_no_fw_cfg_node) {
> > > > > > > we don't really care about SSDT size changes since during
> > > > > > > migration ACPI blobs will be migrated from source, so
> > > > > > > machine compat bloat is excessive here. It would be better
> > > > > > > to just remove it.
> > > 
> > > What about non-live migration?
> > I don't see any issues here, it should just work, since usually
> > original SSDT from source is used (copied as part of migrated ram).
> 
> I mean: shutdown, followed by QEMU upgrade, followed by reboot.
Then guest will get new ACPI tables as well possibly updated BIOS
regardless of machine type. (see below)

> 
> > > > > > 
> > > > > > This was Eduardo's suggestion, if I recall correctly:
> > > > > > 
> > > > > > http://thread.gmane.org/gmane.comp.emulators.qemu/361930/focus=361983
> > > > > > 
> > > > > > The idea being, if you move a guest from older QEMU to newer QEMU, 
> > > > > > but
> > > > > > keep the machine type (or more precisely, the full machine config, 
> > > > > > like
> > > > > > the domain XML) intact, the ACPI device node should not appear out 
> > > > > > of
> > > > > > the blue.
> > > > > This ACPI device is an always used resource declaration regardless
> > > > > of machine type so it makes sense to tell guest about used resource.
> > > > > 
> > > > > The only reason for machine compat code would be if guest suddenly
> > > > > started to ask for a driver but as Gabriel showed with _STA(0xB)
> > > > > it doesn't, so I'm trying to keep ACPI code machine compat agnostic
> > > > > as much as possible.
> > > > 
> > > > Eduardo, what do you think about this ? I'm hoping to do a v5 over the
> > > > weekend or early next week, and which way this should go is one of the
> > > > couple of decisions that I still have open.
> > > 
> > > The general rule is that anything that's visible to the guest shouldn't
> > > change on a QEMU upgrade if the machine-type is kept the same. If we
> > > want to avoid the compat code, we need careful testing to ensure this
> > > won't make any guest OS do something unexpected.
> > > 
> > > One of the things that may break if guest-visible bits of the machine
> > > change is Windows license activation, but the rules Windows use to
> > > trigger reactivation aren't very clear.
> > Practice shows that changing ACPI tables doesn't affect MS Activation so 
> > far.
> 
> I still see any guest-visible change in a machine-type as a bug. But at
> least it seems to be a minor bug.
> 
> I just noticed we have made ACPI table changes in the past without any
> compat code, so that's not something new. So I won't mind too much if
> you really want to avoid acpi_no_fw_cfg_node.
That's because ACPI tables are considered to be part (they are in QEMU for
convenience purpose only) of firmware and as expected if one run's
the same machine type with updated BIOS, one'll get updated tables.

So I prefer to avoid adding compat cruft in ACPI code unless
we have to it, which is not case with this patch.