From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: KVM call agenda for 2013-05-28 Date: Wed, 29 May 2013 11:42:34 +0200 Message-ID: <51A5CD8A.1080801@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <20130529091723.GI4472@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: KVM devel mailing list , Juan Quintela , seabios@seabios.org, qemu-devel qemu-devel , dwmw2@infradead.org To: "Michael S. Tsirkin" Return-path: In-Reply-To: <20130529091723.GI4472@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: seabios-bounces@seabios.org Sender: seabios-bounces@seabios.org List-Id: kvm.vger.kernel.org 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