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

[Gleb Natapov]

On Wed, May 08, 2013 at 06:55:22PM -0400, Kevin O'Connor wrote:
> 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.
> 
If the tables at the source of the migration and the destination
differs and migration happens while seabios is reading them guest
will have corrupted ACPI tables at the destination. The problem is
not new. The same is true for reading option rom or splash screen or
bootindex file, basically anything that we read via fw_cfg interface
and it can be different between two qemu version. The window where the
bug may happen is very small, so we never saw such problem in practice
to my knowledge and the fix should be simple too: migrate fw_cfg that
is been read during migration.

> 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.
> 
+1 again.

--
                        Gleb.