From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmPFC-00011G-6K for qemu-devel@nongnu.org; Wed, 14 Oct 2015 12:49:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmPF9-0006PL-04 for qemu-devel@nongnu.org; Wed, 14 Oct 2015 12:49:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmPF8-0006P5-OV for qemu-devel@nongnu.org; Wed, 14 Oct 2015 12:49:34 -0400 Date: Wed, 14 Oct 2015 13:47:32 -0300 From: Eduardo Habkost Message-ID: <20151014164732.GV1260@thinpad.lan.raisama.net> References: <1443389342-2186-1-git-send-email-somlo@cmu.edu> <1443389342-2186-4-git-send-email-somlo@cmu.edu> <20151001090203.6cf5af1a@nial.brq.redhat.com> <560CEE63.9030909@redhat.com> <20151001133350.5b2c65cc@nial.brq.redhat.com> <20151010040016.GA11819@GLSMBP.INI.CMU.EDU> <20151013191003.GQ1260@thinpad.lan.raisama.net> <20151014104500.44d2cc77@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151014104500.44d2cc77@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: peter.maydell@linaro.org, drjones@redhat.com, matt.fleming@intel.com, mst@redhat.com, "Gabriel L. Somlo" , ard.biesheuvel@linaro.org, qemu-devel@nongnu.org, leif.lindholm@linaro.org, kevin@koconnor.net, kraxel@redhat.com, zhaoshenglong@huawei.com, pbonzini@redhat.com, markmb@redhat.com, Laszlo Ersek , rth@twiddle.net On Wed, Oct 14, 2015 at 10:45:00AM +0200, Igor Mammedov wrote: > On Tue, 13 Oct 2015 16:10:03 -0300 > Eduardo Habkost 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