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: "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 08:08:31 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Grzegorz Milos <gm281@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Peace <Andrew.Peace@xxxxxxxxxxxxx>
Delivery-date: Fri, 18 Dec 2009 00:08:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B2A64EB.3010004@xxxxxxxxx>
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> <20091217163845.GA26398@xxxxxxxxxxxxxxxxxxx> <4B2A719E020000780002679C@xxxxxxxxxxxxxxxxxx> <4B2A64EB.3010004@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Patrick Colp <pjcolp@xxxxxxxxx> 17.12.09 18:05 >>>
>Jan Beulich wrote:
>>>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 17.12.09 17:38 >>>
>>> 1). The  "*mfnp |= 0x80000000U;" and "*mfnp |= 0xf0000000U;" should
>>>    use a #define. Maybe copy over the #defines from the xen tree ?
>> 
>> Did you find any defines in the tools sources for that? The only place I
>> found this condition being checked at all was in xc_map_foreign_pages(),
>> where it used hard-coded values. Or are you referring to the
>> XEN_DOMCTL_PFINFO_* values? I'd say they're being mis-used when
>> applied to the mfn array used by mmap-batch (including apparent
>> pre-existing uses).
>
>I think many people agree that this idea of using 0xf0000000 is a very 
>inelegant solution (myself included). Maybe now would be a good time to 
>hash out what the proper way to deal with this is. I think this discussion 
>should extend to the privcmd/libxc mmap interfaces generally as well.

Yes, I fully agree. While I had cooked together a patch to make the
tools auto-detect whether the underlying (64-bit) kernel uses a
sufficiently wide mask as error indicator (and a Linux side patch to
actually make the kernel behaviorally match the pseudo-documentation
in privcmd.h ("array of mfns - top nibble set on err"), I meanwhile
realized that this would break older tools running on a fixed kernel
(a combination I suppose to be valid).

The only way I can see to solve this is a new ioctl, and if we need a
new ioctl anyway, we can as well design it properly. The question
however is what the best way for an error indication is: Fully over-
writing the passed in MFNs, an extra bit vector passed in (does user
mode have a sufficiently common interface for dealing with bit fields,
like the kernel's bitops.h?), or yet something else?

Jan


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

<Prev in Thread] Current Thread [Next in Thread>