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] page ref/type count overflows

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] page ref/type count overflows
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 26 Jan 2009 14:38:06 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 26 Jan 2009 06:38:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5A376DD.1BE8%keir.fraser@xxxxxxxxxxxxx>
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: <497DD24F.76E4.0078.0@xxxxxxxxxx> <C5A376DD.1BE8%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 26.01.09 15:19 >>>
>On 26/01/2009 14:10, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> But (just having got your second response) if we can do without that ugly
>> cmpxchg8b altogether, then of course this is the much preferred solution.
>> The growing of struct page_info of course isn't very fortunate, but pretty
>> much unavoidable.
>
>I'm having at the cmpxchg8b right now. I'll also widen the fields I guess,
>since that's pretty easy.

The count_info one only, or are you also intending to change _domain?
With struct page_info pretty large already, I'd want to avoid growing it
needlessly.

Partly related to this and partly to the recent heap changes - the need to
constrain the Xen heap to the lower 4G is purely due pickle_domptr(), right?
Wouldn't it make sense to change alloc_domain_struct() then to allocate
a page directly, have pickle_domptr() convert to pfn, and remove the
restriction? Apart from the (auto-ballooning) issues pointed out before, I
realize that such a restriction may make it impossible to create domains
altogether, since there continues to be no way to control what specific
pages can be ballooned out of Dom0 (which as we know has been limiting
the ability to create 32-bit domains).

And in order to possibly buy back the amount the structure will grow now,
wouldn't it make sense to have specialized linked list handling for the
page_info structures that also uses pfn encoding (rather than a full
pointer)?

Jan


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