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] Uses of &frame_table[xfn]

To: "Xen Mailing List" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Uses of &frame_table[xfn]
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Thu, 22 Dec 2005 15:29:18 -0800
Delivery-date: Thu, 22 Dec 2005 23:32:46 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYESuchV2AlvuNuQyaccrlLVAGyUgACPFLgAL4+RdA=
Thread-topic: [Xen-devel] Uses of &frame_table[xfn]
I see that Keir fixed all of these.  Thanks!

The balloon driver in xenlinux was also fixed, but I think
this is a syntactic but not a semantic fix.  In balloon_init,
an assumption is made that all pages below xen_start_info->nr_pages
are valid RAM.  What if all pages of valid RAM are above
nr_pages?  Then (I think) the balloon driver will eat up
all the domain's RAM.  (Unlikely, but you get the drift.)

Or perhaps this assumption is always true on xenlinux/x86
(including PAE and x86_64 and later with VIRTUAL_MEM_MAP)?

I'm still working out what this should be on ia64, but the
current code definitely won't work.  Is it just trying to
allocate N pages where N = max_reservation - initial_reservation?
If so, why not just call alloc_page N times?  If this works,
it is probably shareable with ia64, else perhaps we will
need an arch_balloon_init() (and an asm/balloon.h) otherwise...

On a related note, I'm not clear on the relationship between
the "memory" variable in xmdefconfig and the two reservation
variables needed for ballooning (not sure what they are named,
but call them max_reservation and initial_reservation).  Which
of these latter correspond to "memory" in xmdefconfig and how
does the other get determined?

Thanks,
Dan


> -----Original Message-----
> From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx] 
> Sent: Sunday, December 18, 2005 9:24 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); Xen Mailing List
> Cc: ian.pratt@xxxxxxxxxxxx
> Subject: RE: [Xen-devel] Uses of &frame_table[xfn]
> 
> > There are a number of explicit uses of &frame_table[...] 
> > remaining in Xen common code (grant_table.c and memory.c).
> > Could these be cleaned up to use pfn_to_page(...)?  
> 
> Yes, this is highly desirable. We'll need it for making the 
> frame_table
> virtually mapped to support discontig memory.
> 
> > Eventually, I'd imagine all uses in Xen/x86 should eventually 
> > be changed as well, but this would be a good start.  (And, 
> > yes, there are some in ia64-specific code that I'll be 
> changing too.)
> 
> Please can someone *carefully* work up a patch and test it.
> 
> Ian
> 

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

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