From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNdS-0000xN-NO for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:23:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNdO-0000ur-5w for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:23:54 -0500 Received: from [199.232.76.173] (port=60717 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNdN-0000uk-T4 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:23:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2416) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNdN-0005Ju-Ag for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:23:49 -0500 Date: Sun, 20 Dec 2009 17:23:46 +0200 From: Gleb Natapov Message-ID: <20091220152346.GM4490@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> <20091220150751.GL4490@redhat.com> <4B2E3E96.7090708@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2E3E96.7090708@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 09:11:18AM -0600, Anthony Liguori wrote: > 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 We support only one way of reset: hard reset. It equivalent to full HW power cycling. ACPI spec define ACPI reset as equivalent to HW power cycling too BTW (see 4.7.3.6). > there is really no way to detect (jumping right to BIOS vector). This is not reset at all from qemu POV. No need to reload ROMS. > From a hardware perspective, powering down a CPU and powering it on > again behaves very differently than reset (consider the VT > enablement MSRs). May be you are confusing cpu reset by INIT with CPU reset by power cycling. system_reset (or triple fault or kbd reset or ACPI reset) does the later. > > >>>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. Agree that it is unlikely, but I don't want to be the one debugging it. > > >>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. > This will work only if we assume that rom file size doesn't shrink, -- Gleb.