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