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/emulation/qemu-x86/acpi_tables.c >> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
