From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/NUMA: make init_node_heap() respect Xen heap limit Date: Thu, 27 Aug 2015 11:11:21 +0100 Message-ID: <55DEE249.8070505@citrix.com> References: <55DEE85D020000780009D4FA@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZUuIn-0000gD-H6 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2015 10:21:02 +0000 In-Reply-To: <55DEE85D020000780009D4FA@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: Ian Campbell , Ian Jackson , Keir Fraser , Wei Liu , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 27/08/15 09:37, Jan Beulich wrote: > On NUMA systems, where we try to use node local memory for the basic > control structures of the buddy allocator, this special case needs to > take into consideration a possible address width limit placed on the > Xen heap. In turn this (but also other, more abstract considerations) > requires that xenheap_max_mfn() not be called more than once (at most > we might permit it to be called a second time with a larger value than > was passed the first time), and be called only before calling > end_boot_allocator(). > > While inspecting all the involved code, a couple of off-by-one issues > were found (and are being corrected here at once): > - arch_init_memory() cleared one too many page table slots > - the highmem_start based invocation of xenheap_max_mfn() passed too > big a value > - xenheap_max_mfn() calculated the wrong bit count in edge cases > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper