Re: [Xen-devel] Questions about xen memory management

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-08-08 at 14:59 +0800, Josh Zhao wrote:
> Hi,
> I am reading the arm MM initial code, there are 2 questions I can't
> understand:
> 1)  Both init_xenheap_pages() and init_domheap_pages() will invoke
> init_heap_pages() to initialize pages management.  But there is no
> flag to know those pages are belonged to xenheap or domheap.  Are
> xenhelp and domheap in the same zone?

There are two models for xen vs. domheap, and therefore two version of
init_*heap_pages.

The original model is the split heap model, which is used on platforms
which have smaller virtual address spaces. e.g. arm32, for the moment
arm64 (but I am about to switch to the second model) and historically
the x86_32 platform. This is because as Andy notes xenheap must always
be mapped while domheap is not (and cannot be on these platforms),
domheap is mapped only on demand (map_domain_page).
In this case init_xenheap_pages contains:
    /*
     * Yuk! Ensure there is a one-page buffer between Xen and Dom zones, to
     * prevent merging of power-of-two blocks across the zone boundary.
     */
    if ( ps && !is_xen_heap_mfn(paddr_to_pfn(ps)-1) )
        ps += PAGE_SIZE;
    if ( !is_xen_heap_mfn(paddr_to_pfn(pe)) )
        pe -= PAGE_SIZE;

The second model is used on systems which have large enough virtual
address to map all of RAM, currently x86_64 and soon arm64. In this case
there is only one underlying pool of memory and the split is more
logical than real, although it is tracked by setting PGC_xen_heap when
allocating xenheap pages. In this case domheap is actually always mapped
but you still must use map_domain_page to access it (so common code work
on both models)

There is actually an extension to the second model for systems which
have enourmous amounts of physical memory (e.g. >5TB on x86_64) which
brings back the xen/domheap split but in a different way to the first
model. In this case the split is implemented in alloc_xenheap_pages by
consulting xenheap_bits to restrict the allocations to only the direct
mapped region.

> 2) What's the vmap.c used for ?

To map arbitrary physical addresses into the virtual address space.

>  I saw that only the ioremap will use it.  If so, it seems no needs to
> allocate pages to fill the all VMAP range (256M -  1G) by
> alloc_domheap_page().

This is allocating the page table pages up front which simplifies the
creation of mappings. In theory this could be done on demand but I
suppose it is simpler to do it up front.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel