From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt1pe-0004yG-8m for qemu-devel@nongnu.org; Wed, 30 Sep 2009 12:15:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt1pZ-0004vV-Ck for qemu-devel@nongnu.org; Wed, 30 Sep 2009 12:15:09 -0400 Received: from [199.232.76.173] (port=60257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt1pZ-0004vO-7u for qemu-devel@nongnu.org; Wed, 30 Sep 2009 12:15:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19655) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt1pY-00051V-AG for qemu-devel@nongnu.org; Wed, 30 Sep 2009 12:15:04 -0400 Date: Wed, 30 Sep 2009 18:14:59 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH 00/14] pcbios: support q35 chipset Message-ID: <20090930161459.GJ9832@redhat.com> References: <1254305929-14993-1-git-send-email-yamahata@valinux.co.jp> <4AC35BEF.3040105@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AC35BEF.3040105@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Isaku Yamahata , qemu-devel@nongnu.org On Wed, Sep 30, 2009 at 08:23:59AM -0500, Anthony Liguori wrote: > Isaku Yamahata wrote: > >This patches to pcbios is for q35 chipset. > >This is The change set of da5ff65dc9473e3f069736d38b9a189ea14a67eb > >in git://git.qemu.org/pcbios.git > > Patches against SeaBIOS are also required as we're planning to > switch to SeaBIOS. > > In fact, you don't need to bother with pcbios if you'd rather focus > on SeaBIOS. > > >There would be a discussion to change bioses. > >This patches modifies ACPI DSDT directly which > >is linked into bios binary image. > >This would not be acceptable and it would be a bad > >idea to have two bios binary image for piix and q35. > >So instead, I'm thinking of dynamic loading ACPI table. > >I'd like to hear opinions. What do you think? > > Could we dynamically generate the necessary tables? Using iasl is a > bit problematic as we introduce more knobs via qdev. I expect that > we're going to move to an almost entirely generated set of tables. > Is is almost impossible to dynamically generate DSDT that does nontrivial things. We can use different SSDT for different chipset and decide which one to use in runtime. -- Gleb.