[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.