From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cTu0T-0004T4-SC for qemu-devel@nongnu.org; Wed, 18 Jan 2017 12:26:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cTu0P-0004j5-4h for qemu-devel@nongnu.org; Wed, 18 Jan 2017 12:26:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42236) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cTu0O-0004if-S1 for qemu-devel@nongnu.org; Wed, 18 Jan 2017 12:26:41 -0500 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: Laszlo Ersek Message-ID: Date: Wed, 18 Jan 2017 18:26:36 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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: Ard Biesheuvel Cc: Igor Mammedov , Peter Maydell , Andrew Jones , Al Stone , Graeme Gregory , "Michael S. Tsirkin" , QEMU Developers , Leif Lindholm On 01/18/17 18:02, Ard Biesheuvel wrote: > 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? No, it implies the exact opposite: given that the UEFI firmware is not versioned, and may very well differ on source host and target host, the ACPI payload that QEMU generates (and that the guest OS considers part of the firmware) should be permitted to differ between src and dst host just the same. In brief, for one data point, I'd be fine if we didn't tie this change to machine types. Thanks Laszlo