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. > 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. thanks -- PMM
