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] Paging and memory sharing for HVM guests

To: "Grzegorz Milos" <gm281@xxxxxxxxx>, "Patrick Colp" <pjcolp@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 18 Dec 2009 16:00:08 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Andrew Peace <Andrew.Peace@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 18 Dec 2009 08:06:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <db8ce2bd0912161514s7a162546gf7f5909db22e274c@xxxxxxxxxxxxxx>
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>
References: <db8ce2bd0912161514s7a162546gf7f5909db22e274c@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Grzegorz Milos <gm281@xxxxxxxxx> 17.12.09 00:14 >>>
>The series of 46 patches attached to this email contain the initial
>implementation of memory paging and sharing for Xen. Patrick Colp
>leads the work on the pager, and I am mostly responsible for memory
>sharing. We would be grateful for any comments/suggestions you might
>have. Individual patches are labeled with comments describing their
>purpose and a sign-off footnote. Of course we are happy to discuss
>them in more detail, as required. Assuming that there are no major
>objections against including them in the mainstream xen-unstable tree,
>we would like to move future development to that tree.

So as far as I can tell we now have to colliding values in domctl.h:

#define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)

Was it determined that this is not (going to be) a problem? It's just
the tools interface, but it's a public header...

Also there are several places were gmfn_to_mfn() was replaced by
mfn_x(gfn_to_mfn()), but the p2m_is_valid() check that the former
does was lost. Again - has it been determined that this will never
cause any problem?

Jan


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