Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device

[Igor Mammedov]

On Tue, 17 Jan 2017 10:56:53 +0000
Peter Maydell <address@hidden> wrote:

> On 17 January 2017 at 09:49, Andrew Jones <address@hidden> 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