On Wed, May 29, 2013 at 11:42:34AM +0200, Gerd Hoffmann wrote: > 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
So that would make code PIIX specific. Instead I'm passing in guest_info structure to each object and that describes itself, e.g. sets disable_s3. -- MST
