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). [...]
