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

[Ard Biesheuvel]

On 18 January 2017 at 15:55, Laszlo Ersek <address@hidden> wrote:
> On 01/18/17 16:18, Igor Mammedov wrote:
>> 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)
>
> 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?