|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Questions about xen memory management
On Fri, 2013-08-09 at 11:15 +0800, Josh Zhao wrote:
> Thanks for your reply.
>
> 2013/8/8 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;
>
>
>
> Yes, is_xen_heap_mfn() function can whether the physical address is in
> xenheap or not. But how the init_heap_pages() knows the page is
> belonged to xenheap or domheap. Because the phys_to_nid() always
> return 0;
This is on ARM?
On ARM xenheap pages can be identified by comparing the mfn to
xenheap_mfn_{start,end} -- the xenheap is always a contiguous range of
memory.
phys_to_nid gets you the NUMA node ID which is mostly orthogonal to
xenheap vs domheap.
> As setup_xenheap_mappings() function is one to one mapping xenheap
> physical to 1G--2G virtual space range. I am wondering what the
> Xenheap virtual space(1G-2G) is used for ? Because I can allocate
> xen pages from xenheap by alloc_xenheap_pages() and I can track pages
> by frametable.
I'm not sure what you are asking here. The 1G--2G virtual mapping of the
xenheap exists exactly to satisfy the requirement that xenheap pages are
always mapped IOW __pa and __va work only on xenheap pages.
Sure, you could take a xenheap page, extract the mfn and use
map_domain_page, but why?
> > 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.
>
>
>
>
> In VM_init():
>
>
> for ( i = 0, va = (unsigned long)vm_bitmap; i < nr; ++i, va +=
> PAGE_SIZE )
> {
> struct page_info *pg = alloc_domheap_page(NULL, 0);
>
>
> map_pages_to_xen(va, page_to_mfn(pg), 1, PAGE_HYPERVISOR);
> clear_page((void *)va);
> }
>
>
> It seems not only allocate page table pages ,but also allocates vmap
> pages by alloc_domheap_page().
I'm not sure what you are asking here either.
This is populating the vmap virtual address space, not the xenheap
virtual address space, so it allocates a domheap page and then maps it
explicitly in the appropriate place.
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |