qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.


From: Anthony Liguori
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Date: Sun, 20 Dec 2009 08:58:40 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori <address@hidden>

 Hi,

Option rom saga continued.  This is the first series I consider ready
for merging.  Changes:

 * pci roms: will be loaded via option pci rom bar.
 * non-pci roms: will be loaded via fw_cfg.

Note that using the old bochs-bios based pc-bios will stop working
with this patch series applied.

The last two patches of this series are *not* intended to be merged,
they are just for testing convinience.  They carry a new seabios
binary and the changes needed and turn on bios debug messages in qemu.

Seabios patches will be posted shortly as separate patch series.

I see that this is merged already, but I have a question. How migration
during ROM loading suppose to work?
Magically :-)

Really, we have a fundamentally problem with live migration (that's
orthogonal to this series).  We allocate memory via qemu_ram_alloc()
but we don't have any context to that allocation.  When we migrate
memory, we do so by transferring ram basically in allocation order.

If for some reason allocation order changes, badness ensues.  The
problem is, a lot of devices use qemu_ram_alloc() now and they do so
when they are initialized so the stability of the allocation depends
on the initialization order.  It's exacerbated by things like PCI
hotplug.

We need to make a change in the live migration protocol that
transfers memory identified with tuples (id, chunk offset).  We'll
need to change every qemu_ram_alloc() to take an id argument too.

What will happed if we migrate to newer
qemu with updated vgabios ROM while BIOS is in the middle of loading it on the
source? It seems that destination will have garbled ROM loaded.
During device init, pci device allocates memory, loads rom into
allocated memory.  Upon live migration, allocated memory gets over
written by rom contents from source.  So in this case, it will
actually work today (assuming you get stable ram allocation
offsets).

That much I noticed :), but first after reboot new ROMs should take effect.
Does this happed?

No. You have to physically shut down and start up again. That's the right semantics IMHO.

 Second what if ROM size have changed (on destination it is
smaller)?

Then we're in trouble :-)

 And third what about roms that are loaded with fw_cfg interface (me
mentioning vgabios was not accident :))

vgabios will be loaded as a PCI rom. -std vga still uses fw_cfg but that's a really easy fix.

But the fw_cfg rom loading doesn't seem handle migration :-/

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]