Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

[Kevin O'Connor <kevin@koconnor.net>]

On Wed, May 08, 2013 at 03:35:46PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 08, 2013 at 02:35:44PM +0300, Gleb Natapov wrote:
> > On Wed, May 08, 2013 at 02:07:24PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, May 08, 2013 at 01:59:12PM +0300, Gleb Natapov wrote:
> > > > Where this notion that fw_cfg is only for a small things is coming
> > > > from? I can assure you this was not the case when the device was
> > > > introduced. In fact it is used today for not so small things like
> > > > bootindex splash screen bitmaps, option rom loading and kernel/initrd
> > > > loading. Some of those are bigger then ACPI tables will ever be.
> > > > And they all should be migrated, so fw_cfg should be fixed anyway.
> > > 
> > > I'm not arguing with that. Convince Anthony please.
> > > 
> > Convince him in what? That fw_cfg is broken vrt migration and there are
> > cases that will fail _today_ without any ACPI related changes? This is
> > knows for ages.
> 
> That we should use fw_cfg to load acpi tables.

I'm confused.

ACPI tables are not large.  At most we're talking about 100K of data
total.

I don't see what migration has to do with using fw_cfg to pass acpi
tables - the content is only read at startup.  There may be an issue
for the corner case of VM restarts, but if so it's nothing new.  If
the content of a fw_cfg entry changes during a guest reboot it is
going to have the same impact regardless of whether it's the
"irq0-override" entry / "numa-nodes" entry - or if it's the "madt"
entry / "srat" entry, etc.  So, I don't see how fw_cfg would suddenly
not be suitable.

Again, I recommend that ACPI (and mptable, smbios, pir) be generated
in qemu and that the content be passed to SeaBIOS using one fw_cfg
"file" per table.

-Kevin