WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH, RFC 1/4] linux: add new (replacement) mmap-batch

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, RFC 1/4] linux: add new (replacement) mmap-batch ioctl
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 12 Jan 2010 08:50:22 +0000
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 12 Jan 2010 00:51:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B4C3D4B0200007800029469@xxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqTXyxZSgWUboRWSTaXXn3CYqb0kwABRoHW
Thread-topic: [Xen-devel] [PATCH, RFC 1/4] linux: add new (replacement) mmap-batch ioctl
User-agent: Microsoft-Entourage/12.23.0.091001
On 12/01/2010 08:13, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 12.01.10 08:57 >>>
>> Looked okay to me. The only question I saw was regarding
>> xc_get_pfn_type_xxx: I don't think they are used outside libxc, so you can
>> do whatever makes internal sense for libxc (and remove the decls from
>> xenctrl.h).
> 
> The other question (of wider scope) was that on the save format
> currently used: Using bits 28-31 of the PFNs to encode their types
> (effectively wasting bits 32-63 on 64-bit) isn't forward compatible,
> and hence sooner or later will require a change. But of course there
> are other tools limitations (restricting guests to even smaller amounts
> of memory), but those are mostly internal to the tools (i.e. fixing
> them would not break compatibility).

We'll have to stick some kind of version-bump indicator in the save file,
and change the way PFNs and their types are encoded. This is very doable,
when the development window reopens.

This is definitely a 4.1 feature -- it only prevents us saving 1TB+ guests.
It's quite a separate concern from our support for sparse-memory-map hosts.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel