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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] page ref/type count overflows
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Thu, 29 Jan 2009 10:12:47 +0000
Cc: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 29 Jan 2009 02:13:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4981782A.76E4.0078.0@xxxxxxxxxx>
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: <497EED2B.76E4.0078.0@xxxxxxxxxx> <C5A4914E.1C22%keir.fraser@xxxxxxxxxxxxx> <4981782A.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)
At 08:34 +0000 on 29 Jan (1233218074), Jan Beulich wrote:
> >>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 27.01.09 11:24 >>>
> >On 27/01/2009 10:16, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> >> And shouldn't shadow's count field also be widened to BITS_PER_LONG-6?
> >
> >Would be nice. Hopefully either Tim or Gianluca will see to that.
> 
> Actually, I'd like to go a step further: Is there any reason why struct
> shadow_page_info must be separate from struct page_info (rather than
> sharing the definition, requiring some re-ordering of its elements)?

Well, when it _did_ use struct page_info the code was full of ugly hacks
to wedge information into fields with misleading names. :) I also like
the type-safety of not having the two structs anonymous-unioned
together; it's already confusing which field names are valid at any
time.

I've no objection to having the fields merged if it can be done without
hoicking lots of internal shadow-code definitions back out into common
code (it took me ages to separate it all!), and if it gets some real
benefit (like sharing most of the existing fields).

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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