Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966284AbcKOJpK convert rfc822-to-8bit (ORCPT ); Tue, 15 Nov 2016 04:45:10 -0500 Received: from prv-mh.provo.novell.com ([137.65.248.74]:33880 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S941141AbcKOJpG (ORCPT ); Tue, 15 Nov 2016 04:45:06 -0500 Message-Id: <582AE72D020000780011EBB2@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Tue, 15 Nov 2016 02:45:01 -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> <582AC427020000780011EA7E@suse.com> <582ACEDE020000780011EAC9@suse.com> <478e5d05-ccf6-093e-8301-0eece00ca243@suse.com> In-Reply-To: <478e5d05-ccf6-093e-8301-0eece00ca243@suse.com> 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 Content-Length: 2564 Lines: 54 >>> On 15.11.16 at 09:42, wrote: > On 15/11/16 09:01, Jan Beulich wrote: >>>>> On 15.11.16 at 08:36, wrote: >>> On 15/11/16 08:15, Jan Beulich wrote: >>>>>>> On 15.11.16 at 07:33, wrote: >>>>> 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. >>> >>> The hypervisor interface of XENMEM_machine_memory_map requires to >>> specify the size of the e820 map where the hypervisor can supply >>> entries. The alternative would be try and error: start with a small >>> e820 map and in case of error increasing the size until success. I >>> don't like this approach. Especially as dynamic memory allocations >>> are not possible at this stage (using RESERVE_BRK() isn't any better >>> than a static __initdata array IMO). >> >> Well, I think as a first step we should extend >> XENMEM_{,machine_}memory_map to the model used elsewhere >> where passing in a NULL handle (and perhaps count being zero) is >> a request for the number of needed entries. Granted this doesn't >> help with Linux'es way of consuming the output, but it at least >> allows for dynamic sizing. And Linux would then be free to prepare >> a static array or have a RESERVE_BRK() as it sees fit. > > This still needs the definition of an upper limit, as RESERVE_BRK() > is a compile time feature. That's why I did say "as it sees fit". > For a fully dynamical solution we'd need a way to get a partial > E820 map from the hypervisor (e.g. first 128 entries) in order to > be able to setup at least some memory and later get the rest of > the memory map using some dynamically allocated memory. And we could of course also make the hypercall allow for that (e.g. by defining the semantics of a specific error code, so far not used by it, to avoid mis-interpretation of output on older hypervisors), or introduce a new clone of the existing one(s). Jan