[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device |
Date: |
Wed, 18 Jan 2017 16:55:43 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 |
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.
Laszlo
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, (continued)
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Ard Biesheuvel, 2017/01/16
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Laszlo Ersek, 2017/01/16
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Ard Biesheuvel, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Laszlo Ersek, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Ard Biesheuvel, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Laszlo Ersek, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Michael S. Tsirkin, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Andrew Jones, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Peter Maydell, 2017/01/17
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Igor Mammedov, 2017/01/18
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device,
Laszlo Ersek <=
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Ard Biesheuvel, 2017/01/18
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Laszlo Ersek, 2017/01/18
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Peter Maydell, 2017/01/19
- Re: [Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device, Ard Biesheuvel, 2017/01/18