From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755513AbcKOHPk convert rfc822-to-8bit (ORCPT ); Tue, 15 Nov 2016 02:15:40 -0500 Received: from prv-mh.provo.novell.com ([137.65.248.74]:55108 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751803AbcKOHPi (ORCPT ); Tue, 15 Nov 2016 02:15:38 -0500 Message-Id: <582AC427020000780011EA7E@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Tue, 15 Nov 2016 00:15:35 -0700 From: "Jan Beulich" To: "Juergen Gross" Cc: "David Vrabel" , , "Thomas Gleixner" , , "Ingo Molnar" , "Alex Thorlton" , "Russ Anderson" , , "H. Peter Anvin" Subject: Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries References: <1479168677-23633-1-git-send-email-athorlton@sgi.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 15.11.16 at 07:33, wrote: > On 15/11/16 01:11, Alex Thorlton wrote: >> Hey everyone, >> >> We're having problems with large systems hitting a BUG in >> xen_memory_setup, due to extra e820 entries created in the >> XENMEM_machine_memory_map callback. The change in the patch gets things >> working, but Boris and I wanted to get opinions on whether or not this >> is the appropriate/entire solution, which is why I've sent it as an RFC >> for now. >> >> Boris pointed out to me that E820_X_MAX is only large when CONFIG_EFI=y, >> which is a detail worth discussig. He proposed possibly adding >> CONFIG_XEN to the conditions under which we set E820_X_MAX to a larger >> value than E820MAX, since the Xen e820 table isn't bound by the >> zero-page memory limitations. >> >> I do *slightly* question the use of E820_X_MAX here, only from a >> cosmetic prospective, as I believe this macro is intended to describe >> the maximum size of the extended e820 table, which, AFAIK, is not used >> by the Xen HV. That being said, there isn't exactly a "more >> appropriate" macro/variable to use, so this may not really be an issue. >> >> Any input on the patch, or the questions I've raised above is greatly >> appreciated! > > While I think extending the e820 table is the right thing to do I'm > questioning the assumptions here. > > Looking briefly through the Xen hypervisor sources I think it isn't > yet ready for such large machines: the hypervisor's e820 map seems to > be still limited to 128 e820 entries. Jan, did I overlook an EFI > specific path extending this limitation? No, you didn't. I do question the correlation with "large machines" here though: The issue isn't with large machines afaict, but with ones having very many entries (i.e. heavily fragmented). > In case I'm right the Xen hypervisor should be prepared for a larger > e820 map, but this won't help alone as there would still be additional > entries for the IOAPICs created. > > So I think we need something like: > > #define E820_XEN_MAX (E820_X_MAX + MAX_IO_APICS) > > and use this for sizing xen_e820_map[]. I would say that if any change gets done here, there shouldn't be any static upper limit at all. That could even be viewed as in line with recent e820.c changes moving to dynamic allocations. In particular I don't see why MAX_IO_APICS would need adding in here, but not other (current and future) factors determining the (pseudo) E820 map Xen presents to Dom0. Jan