[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Uses of &frame_table[xfn]


  • To: "Xen Mailing List" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.