[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios |
Date: |
Thu, 25 Jul 2013 18:14:35 +0300 |
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
- Re: [Qemu-devel] [PATCH v3 13/14] hpet: add API to find it, (continued)
- [Qemu-devel] [PATCH v3 11/14] piix: APIs for pc guest info, Michael S. Tsirkin, 2013/07/24
- [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Michael S. Tsirkin, 2013/07/24
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Gerd Hoffmann, 2013/07/25
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Michael S. Tsirkin, 2013/07/25
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Gerd Hoffmann, 2013/07/25
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Gerd Hoffmann, 2013/07/26
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Gerd Hoffmann, 2013/07/26
- Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios, Michael S. Tsirkin, 2013/07/28
[Qemu-devel] [PATCH v3 02/14] i386: add ACPI table files from seabios, Michael S. Tsirkin, 2013/07/24
[Qemu-devel] [PATCH v3 01/14] hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h, Michael S. Tsirkin, 2013/07/24
[Qemu-devel] [PATCH v3 03/14] acpi: add rules to compile ASL source, Michael S. Tsirkin, 2013/07/24
Re: [Qemu-devel] [PATCH v3 00/14] qemu: generate acpi tables for the guest, Andreas Färber, 2013/07/25