From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNok-00066Z-VW for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:35:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNog-00063d-2A for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:35:34 -0500 Received: from [199.232.76.173] (port=41822 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNof-00063R-RN for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:35:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15514) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNof-0007qw-Bu for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:35:29 -0500 Message-ID: <4B2E443E.6080303@redhat.com> Date: Sun, 20 Dec 2009 17:35:26 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. 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> <4B2E40C7.2080908@redhat.com> <4B2E434F.4050606@codemonkey.ws> In-Reply-To: <4B2E434F.4050606@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gerd Hoffmann , Gleb Natapov , qemu-devel@nongnu.org On 12/20/2009 05:31 PM, Anthony Liguori wrote: > Avi Kivity wrote: >>> 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. >> >> Currently live migration uses ram_addrs, so this would work. But >> ram_addrs have no meaning in the guest and thus depend on qemu >> implementation details. IMO we should switch live migration to use >> guest physical addresses, which would require a different migration >> implementation for roms. Most of it can be shared with ram, though. > > I'd rather do (id, offset) instead of guest physical address. Guest > physical addresses map to ram_addrs in chunks. Each chunk usually has > some reasonable identification (below 640k, above 1mb, above 4gb, > etc.). Other type of memory like roms and vga lfb memory aren't > always part of the guest physical address space but nonetheless still > need to be migrated. This gives us one mechanism to support everything. > What about hotplugged memory? I guess we can introduce the notion of user-visible memory slots; those exist on real hardware as well. These slots would be different from the kvm memory slots, of course. ids do have a nice property in that pci memory can be migrated while its BAR changes. With gpa you'd need special handling. -- error compiling committee.c: too many arguments to function