From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNFB-00085M-Qh for qemu-devel@nongnu.org; Sun, 20 Dec 2009 09:58:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNF7-00082S-Cn for qemu-devel@nongnu.org; Sun, 20 Dec 2009 09:58:49 -0500 Received: from [199.232.76.173] (port=60979 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNF7-00082L-8g for qemu-devel@nongnu.org; Sun, 20 Dec 2009 09:58:45 -0500 Received: from mail-iw0-f197.google.com ([209.85.223.197]:40142) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNF6-0008Ie-Pw for qemu-devel@nongnu.org; Sun, 20 Dec 2009 09:58:45 -0500 Received: by iwn35 with SMTP id 35so3038379iwn.4 for ; Sun, 20 Dec 2009 06:58:43 -0800 (PST) Message-ID: <4B2E3BA0.7080004@codemonkey.ws> Date: Sun, 20 Dec 2009 08:58:40 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1261134074-11795-1-git-send-email-kraxel@redhat.com> <20091220083857.GE4490@redhat.com> <4B2E381A.4080804@codemonkey.ws> <20091220145200.GA6706@redhat.com> In-Reply-To: <20091220145200.GA6706@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Gerd Hoffmann , qemu-devel@nongnu.org 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 >>>> >>>> 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