From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: Vmap allocator fails to allocate beyond 128MB Date: Mon, 16 Feb 2015 10:57:35 +0000 Message-ID: <54E1CD1F.2020706@linaro.org> References: <54257C510200007800039A83@mail.emea.novell.com> <5425A7A50200007800039D5C@mail.emea.novell.com> <54291B24020000780003A3AA@mail.emea.novell.com> <542925E0020000780003A410@mail.emea.novell.com> <54E1C659.5000006@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: Ian Campbell , Stefano Stabellini , Prasun Kapoor , manish.jaggi@caviumnetworks.com, Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 16/02/15 10:50, Vijay Kilari wrote: > On Mon, Feb 16, 2015 at 3:58 PM, Julien Grall 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. >> >>> 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. >> >> I don't know which approach is the best, and I though you already talked >> about it with Jan... But in general a generic approach is better than a >> per-architecture solution. > > When I say architecture specific, I mean, a common function will be > created and implemented in architecture specific files similar to > map_pages_to_xen. This new function will wrap the required code > for per-architecture. I would advice you to send an RFC on the mailing list. So we have a base to talk about it. Regards, -- Julien Grall