From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2NEG-00041g-5m for qemu-devel@nongnu.org; Thu, 25 Jul 2013 11:13:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2NEC-0000DE-KF for qemu-devel@nongnu.org; Thu, 25 Jul 2013 11:13:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2NEC-0000CN-B2 for qemu-devel@nongnu.org; Thu, 25 Jul 2013 11:13:16 -0400 Date: Thu, 25 Jul 2013 18:14:35 +0300 From: "Michael S. Tsirkin" Message-ID: <20130725151435.GE3758@redhat.com> References: <1374681580-17439-1-git-send-email-mst@redhat.com> <1374681580-17439-15-git-send-email-mst@redhat.com> <51F122D1.4010600@redhat.com> <20130725132301.GA2575@redhat.com> <51F13D0C.20602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F13D0C.20602@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Anthony Liguori , qemu-devel@nongnu.org On Thu, Jul 25, 2013 at 04:58:20PM +0200, Gerd Hoffmann wrote: > On 07/25/13 15:23, Michael S. Tsirkin wrote: > > On Thu, Jul 25, 2013 at 03:06:25PM +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >>> As table content is likely to change over time, > >>> the following measures are taken to simplify > >>> cross-version migration: > >>> - All tables besides the RSDP are packed in a single FW CFG entry. > >>> This entry size is currently 23K. We round it up to 64K > >>> to avoid too much churn there. > >> > >> Does it need to be that way? I'd prefer to have one fw_cfg entry per table. > >> > >> cheers, > >> Gerd > >> > > > > It's better I think. The advantages are: > > - when we add more tables we don't break cross-version > > migration compatibility > > New tables are a guest-visible change, so I think we have to turn them > off for old machine types via compat properties anyway. This will also > solve the migration issue. ACPI is really part of bios. We *do* make guest visible changes to bios rom, so I'm not so sure we should take a hard-line stance on this. > > - we have limited number of files, this way we won't > > run out of them > > Anything which prevents us from raising that number? There's a static array so we can extend it a bit, but making it large and dynamic is hard. I *really* want to keep the number of moving parts to minimum, this is a huge patchset as it is. So please, let's keep it simple, and have everything in one file, and we can move things around later any number of times if/when the need arises. > > what are advantages of file per table? > > You can look at the tables without doing a full linker pass first, so > the firmware can easily initialize the hardware according to what it > finds in specific acpi tables. Check FADT for pm_base. Check MCFG for > mmconf xbar location. > > cheers, > Gerd That's something I think that it's best for firmware to avoid. Much better to load tables in memory and use standard ACPI methods to find specific tables. It's a general thing: paravirtualization is often easier but let's use standard interfaces where possible. Sticking everything in one file will serve to keep firmware honest and not let it cut corners. -- MST