This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] guest kexec / domU boot loader

To: Gerd Hoffmann <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] guest kexec / domU boot loader
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 15 Mar 2006 11:51:15 +0000
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 15 Mar 2006 11:51:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4417FD30.6020802@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44115A90.2050303@xxxxxxx> <7ab24978871318ae238e7e362c861706@xxxxxxxxxxxx> <4417FD30.6020802@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 15 Mar 2006, at 11:40, Gerd Hoffmann wrote:

With auto_translate, you should use the new MEMOP_add_to_physmap call.
It allows you to move shared_info and grant_table pages around in the
physmap space (if you call and they already have a mapping, the old
mapping goes away).

What happens with the place where the mapping was?  Does a hole appear
there or is the "magic" page replaced by a normal page?  Can I move the
console and xenstore pages too?

You end up with a hole there. Can be filled with MEMOP_populate_physmap if you wish. The console and xenstore pages cannot currently be moved, but I can add support. Since the only handle the guest has on those is their current gpfn, and Xen doesn't know about their special status, the best approach is probably to add another 'source space' to the MEMOP_add_to_physmap call, effectively allowing you to move a memory page from one gpfn to another by specifying the source and target gpfns.

Sound good?

 -- Keir

Xen-devel mailing list