Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios

["Michael S. Tsirkin" <mst@redhat.com>]

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