From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTs0K-0001WA-DV for qemu-devel@nongnu.org; Wed, 18 Jan 2017 10:18:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cTs0G-0000sa-8I for qemu-devel@nongnu.org; Wed, 18 Jan 2017 10:18:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50922) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cTs0F-0000rC-Vy for qemu-devel@nongnu.org; Wed, 18 Jan 2017 10:18:24 -0500 Date: Wed, 18 Jan 2017 16:18:19 +0100 From: Igor Mammedov Message-ID: <20170118161819.7f5526af@nial.brq.redhat.com> In-Reply-To: References: <1484328738-21149-1-git-send-email-ard.biesheuvel@linaro.org> <20170117094950.5dqdpbk6u7p4yhms@kamzik.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Peter Maydell Cc: Andrew Jones , Ard Biesheuvel , Leif Lindholm , QEMU Developers , Graeme Gregory , Al Stone , "Michael S. Tsirkin" 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) > > thanks > -- PMM