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

[Laszlo Ersek]

On 01/18/17 18:02, Ard Biesheuvel wrote:
> 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?

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