On Wed, Oct 14, 2015 at 10:45:00AM +0200, Igor Mammedov wrote:
> On Tue, 13 Oct 2015 16:10:03 -0300
> Eduardo Habkost <ehabk...@redhat.com> 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
