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:43:38 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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).

Regards,

Anthony Liguori




reply via email to

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