From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: page faults on machines with > 4TB memory Date: Fri, 24 Jul 2015 04:01:17 -0600 Message-ID: <55B2290D02000078000950C1@prv-mh.provo.novell.com> References: <20150723163556.GA13434@elena.ufimtseva> <55B11DF9.4030002@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55B11DF9.4030002@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , xen-devel@lists.xen.org, Elena Ufimtseva Cc: adnan.misherfi@oracle.com List-Id: xen-devel@lists.xenproject.org >>> On 23.07.15 at 19:01, wrote: > Observe that ffff8840ffdb53c0 is actually a pointer in the 64bit PV > virtual region, because the xenheap allocator has wandered off the top > of the directmap region. This is a direct result of passing numa node > information to alloc_xenheap_page(), which overrides the check which > keeps the allocation inside the directmap region. Does it? Looking at the code I can't see why it would: alloc_heap_pages() only ever looks at [zone_lo, zone_hi], regardless of requested node, and alloc_domheap_pages() determines the zone range based on the bit width requested by the caller (alloc_xenheap_pages() in this case, unless its caller has asked for a smaller address width or xenheap_bits isn't set). Jan