Re: [Xen-devel] Vmap allocator fails to allocate beyond 128MB

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

Hi Ian,

  For ThunderX/arm64 this issue needs to be fixed.
Could you please comment on this?

I could think of below

        1) Add new call for ARM under CONFIG_ARM_32/CONFIG_ARM_64
in vm_init() and manage map_pages_to_xen(va, 0, vm_low - nr, MAP_SMALL_PAGES);
with different function call for arm that would not make any pte
entries for vm_bitmap pages.
This avoids change to x86

        2) Remove map_pages_to_xen(va, 0, vm_low - nr,
MAP_SMALL_PAGES) from vm_init
and add new architecture specific for initializing vm_bitmap pages.
But this touches
x86 code.


Regards
Vijay

On Mon, Sep 29, 2014 at 12:56 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 29.09.14 at 09:10, <vijay.kilari@xxxxxxxxx> wrote:
>> We don't need to allocate page table structures in vm_init
>> for vm_bitmap reserved pages  because this  virtual addresses are
>> reserved for vm_bitmap and are not given to anyone by vm_alloc.
>> So page table structures can be created when actual allocation
>> requests comes in for vm_bitmap.
>
> They could, but did you check what that would mean to code
> complexity? In particular the current approach avoids calling
> map_pages_to_xen() in ways where it might need to do allocations
> (to establish page tables) while already holding a spin lock in the
> caller. Please remember that while it is not strictly forbidden in Xen
> to do (page) allocations with a lock held, it is bad practice and
> should hence be avoided where possible.
>
> Jan
>

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