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

[Eduardo Habkost]

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.

> > > > > 
> > > > > 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.

-- 
Eduardo