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
