On 01/18/17 16:18, Igor Mammedov wrote: > On Tue, 17 Jan 2017 10:56:53 +0000 > Peter Maydell <peter.mayd...@linaro.org> wrote: > >> On 17 January 2017 at 09:49, Andrew Jones <drjo...@redhat.com> 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
