From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhcxe-0000Jf-NS for qemu-devel@nongnu.org; Wed, 29 May 2013 05:46:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uhcxa-0007iH-Ca for qemu-devel@nongnu.org; Wed, 29 May 2013 05:46:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhcxa-0007i8-4k for qemu-devel@nongnu.org; Wed, 29 May 2013 05:46:22 -0400 Date: Wed, 29 May 2013 12:46:17 +0300 From: "Michael S. Tsirkin" Message-ID: <20130529094616.GL4472@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <20130529091723.GI4472@redhat.com> <51A5CD8A.1080801@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A5CD8A.1080801@redhat.com> Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: KVM devel mailing list , Juan Quintela , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , dwmw2@infradead.org 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