On 13/03/2020 12:05, Igor Mammedov wrote:
On Thu, 12 Mar 2020 19:28:31 +0200
Liran Alon <liran.a...@oracle.com> wrote:
On 12/03/2020 18:27, Igor Mammedov wrote:
On Wed, 11 Mar 2020 19:08:26 +0200
Liran Alon <liran.a...@oracle.com> wrote:
+
[...]
we typically do not version ACPI table changes (there might be exceptions
but it should be a justified one).
ACPI tables are considered to be a part of firmware (even though they are
generated by QEMU) so on QEMU upgrade user gets a new firmware along with
new ACPI tables.
Hmm... I would have expected as a QEMU user that upgrading QEMU may
update my firmware exposed table (Such as ACPI),
but only if I don't specify I wish to run on a specific machine-type. In
that case, I would've expect to be exposed with exact same firmware
information.
That would be ideal but it's not the case with current QEMU, even with
specific machine type user will get new firmware when it's started with
upgraded QEMU which usually ships with new firmware.
mgmt layer theoretically can take care of maintaining different firmwares
on host and explicitly specify which should be used (though I'm not aware
of any doing it)
another issue with adding flags consistently for every acpi related
change would complicate code quite a bit making it hard to read/maintain,
hence flags are used only when we have to introduce them (i.e when it
would break guest).
I understood that this was one of the main reasons why ACPI/SMBIOS
generation was moved from SeaBIOS to QEMU.
If I recall correctly, Michael moved table to QEMU so we won't have to
extend ABI for constantly growing ACPI interface and then maintain it
forever, which indeed would require using compat machinery for every
knob (which is unsustainable).
[...]
Ok. Thanks very much for expressing your opinion.
So I would just remove flag and submit v2 without it.
-Liran
