From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNRQ-0000eC-Nc for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:11:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNRK-0000cb-Mu for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:11:27 -0500 Received: from [199.232.76.173] (port=59174 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNRK-0000cW-I5 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:11:22 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:63133) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNRK-0002cN-BC for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:11:22 -0500 Received: by yxe26 with SMTP id 26so4331736yxe.4 for ; Sun, 20 Dec 2009 07:11:21 -0800 (PST) Message-ID: <4B2E3E96.7090708@codemonkey.ws> Date: Sun, 20 Dec 2009 09:11:18 -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> <4B2E3BA0.7080004@codemonkey.ws> <20091220150751.GL4490@redhat.com> In-Reply-To: <20091220150751.GL4490@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:58:40AM -0600, Anthony Liguori wrote: > >> 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. > Not at all. Reset can happen in a lot of different ways, some that there is really no way to detect (jumping right to BIOS vector). From a hardware perspective, powering down a CPU and powering it on again behaves very differently than reset (consider the VT enablement MSRs). >>> 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. > Practically speaking, I don't think it's a huge problem to be honest. It's a very unlikely scenario. We could make the rom size a qdev property which would allow a user to explicitly deal with this case. >> But the fw_cfg rom loading doesn't seem handle migration :-/ >> >> > Looks like it. We should send them over during migration too. > We should just qemu_ram_alloc() that memory regardless of whether we every map it into the guest. Since roms can be large, we want to send their contents over during the live part of migration. If we use qemu_ram_alloc(), we get that for free. Regards, Anthony Liguori