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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Uses of &frame_table[xfn]
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Fri, 23 Dec 2005 05:28:11 -0800
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 23 Dec 2005 13:31:26 +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: AcYHtda1+4cWldXaSyWBnNq2WX5fAgAC7xPw
Thread-topic: [Xen-devel] Uses of &frame_table[xfn]
> > 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.)
> 
> The assumption is that you are initially allocated contiguous 
> RAM from 
> pseudophys page frame 0 up to pseudophys page frame nr_pages-1.

> A further assumption is that, if the max_pfn is larger than nr_pages, 
> the physical space between nr_pages and max_pfn is not (yet) 
> populated 
> with RAM. Thus those pages properly belong to the balloon driver.
> 
> Are these assumptions not workable on ia64?

Ah, I see.  For unprivileged domains, this assumption is also valid
on ia64 (though from Ewan's reply, I gather this is is a no-op
for unprivileged domains because max_pfn==nr_pages at launch?).

Dom0 is different on ia64 because it is direct-mapped
(physical == machine).  The machine memory map
(aka EFI memory map) on ia64 machines may be sparse
and full of holes.  In particular, dom0 on ia64 currently
starts at machine memory 256M.  I'm fairly sure the
PageReserved check will avoid ballooning any of the holes,
but the assumption of linear counting from zero would result in
an incorrect total.  (On top of that, the plumbing for
start_info->nr_pages is currently broken on ia64 as it
is set to zero :-)

> the physical space between nr_pages and max_pfn is not (yet) 
> populated with RAM

How do you manage that? Does "not populated" mean there is no
struct page for them?  Will a get_free_page work on them?
We just tracked down a horrific problem involving missing
dom0 struct pages on Xen/ia64 so I want to make sure I understand
this and get it right.

If there is a struct page and the Linux allocator can handle
the pages, my previous suggestion of replacing the code with
alloc'ing N pages should work for both (x86 and ia64).  If not,
how do you feel about replacing that memory initialization
stanza with a call to arch_balloon_init (and creating a new
asm/balloon.h file)?

Thanks,
Dan


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

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