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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> > 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?).
> 
> Very early on in boot we increase max_pfn beyond nr_pages and 
> allocate 
> a suitably large mem_map so that there are struct page's covering the 
> whole space.

OK.  That is done on Xen/ia64 also but it is done in Xen
rather than by changing Xenlinux.  Where is the code in
Xenlinux/x86 that does this?  (It may be educational...)
 
> >> 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.
> 
> Yeah, they have struct page, but there is no memory mapped at that 
> kernel virtual address (the phys2mach entry points nowhere).

Just to make sure I understand:  After domain0 starts and before
any other domains start, the balloon list contains the dom0 kernel
virtual address of all pages that _could_ be backed by RAM
in the future, but aren't yet?  Then is the balloon list a
dom0-land representation of _all_ the pages in Xen's domheap
or just a subset?  (I'm guessing the latter... Xen uses the
non-dom0 pages from the domheap to create new domains, but
if the domheap eventually runs dry, Xen sucks pages away from
dom0, correct?)

> > 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)?
> 
> Alloc'ing N pages would not guarantee to get exactly the 
> pages we want 
> (i.e., the ones with no RAM). The mem initialization as is does not 
> look particularly x86 specific. Is the check for PageReserved a 
> problem? If so, we can probably work around that -- it's only used to 
> skip over highmem pages in non-highmem i386 kernels.

No, I think PageReserved is also used in Linux/ia64 to mark pages
that are holes in the memmap, so that check is OK.  The problem
is that on ia64 it is NOT the case that all dom0 pages below
start_info->nr_pages "have RAM", e.g. some (perhaps most) of the
pages below nr_pages are PageReserved.  But some of them
may be PageReserved because they do not "have RAM" (meaning on
ia64 that there is a hole there) and some may be PageReserved
for other reasons (e.g. that's where kernel text lives) so I
don't think any kind of linear-page-walk algorithm
will work.

I expect that in the future you may not want to have this
linear-page-walk code in a driver anyway as it may become
subject to lots of CONFIG_WEIRD_MEMORY options on different
arch's (maybe even x86-64?).

Thanks,
Dan

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