From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNO4-0007jB-7C for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:08:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNNz-0007iV-99 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:07:59 -0500 Received: from [199.232.76.173] (port=51871 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNNz-0007iS-6i for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:07:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49359) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNNy-0001sU-MY for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:07:54 -0500 Date: Sun, 20 Dec 2009 17:07:51 +0200 From: Gleb Natapov Message-ID: <20091220150751.GL4490@redhat.com> References: <1261134074-11795-1-git-send-email-kraxel@redhat.com> <20091220083857.GE4490@redhat.com> <4B2E381A.4080804@codemonkey.ws> <20091220145200.GA6706@redhat.com> <4B2E3BA0.7080004@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2E3BA0.7080004@codemonkey.ws> 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: Anthony Liguori Cc: Gerd Hoffmann , qemu-devel@nongnu.org On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote: > 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. > Reset is equivalent (or should be) to shut down and start up again. > > Second what if ROM size have changed (on destination it is > >smaller)? > > Then we're in trouble :-) > Yeah, we are. May be relaying on file size is not good enough heuristic to determine ROM BAR size. > > 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. I mean -std vga and other "genroms" (multiboot, linuxboot, vapic). > > But the fw_cfg rom loading doesn't seem handle migration :-/ > Looks like it. We should send them over during migration too. -- Gleb.