Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752194AbcKOLMn convert rfc822-to-8bit (ORCPT ); Tue, 15 Nov 2016 06:12:43 -0500 Received: from prv-mh.provo.novell.com ([137.65.248.74]:42342 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbcKOLMl (ORCPT ); Tue, 15 Nov 2016 06:12:41 -0500 Message-Id: <582AFBB6020000780011ED0B@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Tue, 15 Nov 2016 04:12:38 -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> <582AE72D020000780011EBB2@suse.com> <4bac3691-f157-4acc-7b29-7c49be6d35d6@suse.com> <582AF51F020000780011ECB4@suse.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 Content-Length: 1503 Lines: 35 >>> On 15.11.16 at 12:07, wrote: > On 15/11/16 11:44, Jan Beulich wrote: >>>>> On 15.11.16 at 10:55, wrote: >>> On 15/11/16 10:45, Jan Beulich wrote: >>>>>>> On 15.11.16 at 09:42, wrote: >>>>> 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). >>> >>> I'd go with the new error code. What about E2BIG or ENOSPC? >> >> Either seems fine. >> >>> I think the hypervisor should fill in the number of entries required >>> in this case. >> >> And you'd then mean the caller to imply that the passed in (and now >> overwritten) count to describe how many entries got filled? That's >> not that nice an interface. I'd rather return the number of entries >> filled, and require the sizing variant (NULL handle) to be used to >> obtain the number of entries. After all if a caller _wants_ to handle >> a partial map, it doesn't really care how many further entries there >> are. > > I just wanted to avoid two interface changes. Just make one at a time. Jan