Hi,
possible complexity of having to regenerate tables on a vm reboot,
Why tables should be regenerated at reboot? I remember hotplug being mentioned in the call. Hmm? Which hotplugged component needs acpi table updates to work properly? And what is the point of hotplugging if you must reboot the guest anyway to get the acpi updates needed? Details please.
I think it's a mistake. I sent a mail explaining this part.
Saw it meanwhile.
Also mentioned in the call: "architectural reasons", which I understand as "real hardware works that way". Correct.
Not exactly. Real hardware is very likely to have most of the tables pre-generated in ROM, load them and tweak them in the minor way.
From a quick look it seems coreboot has a static (iasl-compiled) dsdt
and generates everything else.
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/emul...
Agree on this one. Ideally the acpi table generation code should be able to gather all information it needs from the qom tree, so it can be a standalone C file instead of being scattered over all qemu.
Did you look at the patchset I posted?
Very briefly only.
Generation is in a standalone C file there.
Good.
However, if you mean we should do things like
if (Device_id == foobar) { } in once central place, I disagree. I think that's nasty, adding devices would mean touching this central registry.
No, I mean more "lookup PIIX4_PM object + check disable_s3 property" instead of having code for it in hw/acpi/piix4.c or using global variables.
cheers, Gerd