From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NMNkt-0004Ko-Ck
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:31:35 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NMNko-0004Hv-I5
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:31:34 -0500
Received: from [199.232.76.173] (port=52990 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NMNko-0004Hp-Bj
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:31:30 -0500
Received: from mail-iw0-f197.google.com ([209.85.223.197]:34069)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NMNko-00072p-0n
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:31:30 -0500
Received: by iwn35 with SMTP id 35so3048134iwn.4
	for <qemu-devel@nongnu.org>; Sun, 20 Dec 2009 07:31:29 -0800 (PST)
Message-ID: <4B2E434F.4050606@codemonkey.ws>
Date: Sun, 20 Dec 2009 09:31:27 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
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>
In-Reply-To: <4B2E40C7.2080908@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>, Gleb Natapov <gleb@redhat.com>, qemu-devel@nongnu.org

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.

Regards,

Anthony Liguori