From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTtcb-0000i8-VV for qemu-devel@nongnu.org; Wed, 18 Jan 2017 12:02:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cTtcY-0002Qx-0D for qemu-devel@nongnu.org; Wed, 18 Jan 2017 12:02:06 -0500 Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]:37548) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cTtcX-0002Qq-RD for qemu-devel@nongnu.org; Wed, 18 Jan 2017 12:02:01 -0500 Received: by mail-it0-x232.google.com with SMTP id r185so15172095ita.0 for ; Wed, 18 Jan 2017 09:02:01 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <9dcc7f51-1763-e3bf-6879-7955d9ad23de@redhat.com> References: <1484328738-21149-1-git-send-email-ard.biesheuvel@linaro.org> <20170117094950.5dqdpbk6u7p4yhms@kamzik.brq.redhat.com> <20170118161819.7f5526af@nial.brq.redhat.com> <9dcc7f51-1763-e3bf-6879-7955d9ad23de@redhat.com> From: Ard Biesheuvel Date: Wed, 18 Jan 2017 17:02:00 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Igor Mammedov , Peter Maydell , Andrew Jones , Al Stone , Graeme Gregory , "Michael S. Tsirkin" , QEMU Developers , Leif Lindholm On 18 January 2017 at 15:55, Laszlo Ersek wrote: > On 01/18/17 16:18, Igor Mammedov wrote: >> On Tue, 17 Jan 2017 10:56:53 +0000 >> Peter Maydell wrote: >> >>> On 17 January 2017 at 09:49, Andrew Jones wrote: >>>> In some cases the problem we're solving with the compat guards is >>>> a bit hypothetical, but, IMHO, nonetheless a good practice. While >>>> we may be sure that AAVMF and Linux will be fine with this table >>>> changing under their feet, we can't be sure there aren't other >>>> mach-virt users that have more sensitive firmwares/OSes. An ACPI- >>>> sensitive OS may notice the change on its next reboot after a >>>> migration, and then simply refuse to continue. >>> >>> There's also the case where you do a VM migration midway through >>> UEFI booting up, I think, which might cause things to go wrong >>> if you catch it just at the wrong moment. >> acpi blobs are migrated from source so above won't happen. >> The time guest will see new table is fresh boot or reboot. >> >>> >>>> Now, that said, I just spoke with Igor in order to learn the x86 >>>> practice. He says that the policy has been more lax than what I >>>> suggest above. Hypothetical, low-risk issues are left unguarded, >>>> and only when a bug is found during testing is it then managed. >>>> The idea is to try and reduce the amount of compat variables and >>>> conditions needed in the ACPI generation code, but, of course, at >>>> some level of risk to users expecting their versioned machine type >>>> to always appear the same. >>>> >>>> So far we've been strict with mach-virt, guarding all hypothetical >>>> issues. Perhaps this patch is a good example to get a discussion >>>> started on whether or not we should be so strict though. >>> >>> That said, I don't have a very strong opinion here, beyond that >>> we should be consistent at least with x86 practice. >> another reason why we are trying not to use strict approach with ACPI >> tables is that it's part of firmware and we didn't version firmwares >> so far. (i.e. dst host with newer QEMU will typically have newer >> firmware and guest with old machine-type migrated to host with newer >> QEMU will run new firmware on (re)boot) > > I haven't been aware of this argument, and I'm surprised by it, but I > think it's valid. Regardless of our choice to ultimately compose the > ACPI tables in QEMU, guest OSes definitely consider ACPI as part of the > firmware. So, different ACPI content after a migration + guest reboot on > the target host is not much different from any other firmware-level > changes encountered on the same target host, after reboot. > I agree. But does that imply that this fix should be tightly coupled to the mach-virt version, considering that the UEFI firmware you run *inside* such a vm is not versioned either?