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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 16/02/15 10:57, Julien Grall wrote:
> On 16/02/15 10:50, Vijay Kilari wrote:
>> On Mon, Feb 16, 2015 at 3:58 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>> wrote:
>>> On 16/02/15 10:17, Vijay Kilari wrote:
>>>
>>> Hello Vijay,
>>>
>>>>   For ThunderX/arm64 this issue needs to be fixed.
>>>> Could you please comment on this?
>>>
>>> AFAICS, x86 is also using a 1G area for the vmap. Does it mean that x86
>>> never use vmap for more than 128M?
>>
>> I think for x86 there is no problem. It works beyond 128M
> 
> Did you test it? The code seems common enough to make the problem
> appears on x86.

So I've looked at the code and read twice the whole thread.

On a previous mail [1], Jan said that x86 doesn't set the present bit
when it's not required.

The first time that map_pages_to_xen is called to this region (in
vm_init), MAP_SMALL_PAGES is used. Looking to the x86 definition, the
present bit is not set.

On the second call (see vm_alloc), PAGE_HYPERVISOR is used. This define
will set the present bit.

Now about ARM... MAP_SMALL_PAGES is defined as PAGE_HYPERVISOR and the
page is mapped in any case.

So it looks like to me that the buggy code is not the vmap code but the
ARM Xen Page Table code.

IHMO, we have to introduce the concept of mapping region with
non-present bit on ARM. This would allow us to populate the table during
the initialization and allow to map a page (such as the bitmap) in
constant time later.

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2014-09/msg04307.html

-- 
Julien Grall

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