[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Vmap allocator fails to allocate beyond 128MB
>>> On 29.09.14 at 07:42, <vijay.kilari@xxxxxxxxx> wrote: > On Fri, Sep 26, 2014 at 9:21 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>> On 26.09.14 at 17:23, <vijay.kilari@xxxxxxxxx> wrote: >>> In the call map_pages_to_xen() after for loop is performing the mapping >>> for next vm_bitmap pages. In case of arm this call will set valid bit >>> is set to 1 in pte >>> entry for this mapping. >> >> So _that_ is the bug then, because ... >> >>> void __init vm_init(void) >>> { >>> .... >>> 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); >>> } >>> bitmap_fill(vm_bitmap, vm_low); >>> >>> /* Populate page tables for the bitmap if necessary. */ >>> map_pages_to_xen(va, 0, vm_low - nr, MAP_SMALL_PAGES); >> >> ... here we don't request any valid leaf entries to be created. All we >> want are the non-leaf page table structures. > > Do we need to reserve this non-leaf page table structures? > If vm_low is reserving the virtual address, vm_alloc will not allocate > vm_bitmap reserved pages. Not sure what you mean with "reserve" here. Again - we want the page table structures to be created (without handing out the respective virtual addresses to anyone), so that we don't need to be bothered with this when actual allocation requests come in. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |