From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v2 07/12] x86/altp2m: add control of suppress_ve. Date: Tue, 07 Jul 2015 09:04:41 +0100 Message-ID: <559BA439020000780008D2CB@mail.emea.novell.com> References: <1434999372-3688-1-git-send-email-edmund.h.white@intel.com> <1434999372-3688-8-git-send-email-edmund.h.white@intel.com> <558ADCEE0200007800088FF7@mail.emea.novell.com> <558AEEA8.1000305@intel.com> <558BD42502000078000895BD@mail.emea.novell.com> <558C2E05.3040300@intel.com> <558D079F0200007800089F82@mail.emea.novell.com> <558D7D88.1050100@intel.com> <559ABC64.4080503@intel.com> <559AC926.7010707@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559AC926.7010707@eu.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: George Dunlap , Ed White Cc: Tim Deegan , Ravi Sahita , Wei Liu , Andrew Cooper , Ian Jackson , "xen-devel@lists.xen.org" , tlengyel@novetta.com, Daniel De Graaf List-Id: xen-devel@lists.xenproject.org >>> On 06.07.15 at 20:29, wrote: > On 07/06/2015 06:35 PM, Ed White wrote: >> I certainly don't want to speak for Jan, but my reading of his >> comments suggests that wouldn't be enough to satisfy him. He >> seemed to me to object to the whole idea of adding something >> specifically to handle suppress_ve, and thought any change should >> offer a more general 'control extra (E)PTE bits' interface. > > I understood Jan's objection to be to adding two extra hooks ("But then > it seems questionable how they could be useful to the generic p2m layer > anyway, i.e. why there would need to be such hooks in the first > place."), instead of just adding an extra field to the existing > [gs]et_p2m_entry() ("But thinking about it more, I would suggest to > extend the existing accessors rather than adding new ones.") > > He does suggest the idea of making the interface generic, by for example > making it an extentable "flags" argument, or by changing the whole thing > to accept a pointer to a struct, rather than adding more and more > arguments that need to be set (and which, like p2m_access_t, almost > everybody just either uses the default or passes on what was passed to > them), add a pointer to a struct ("One might even consider folding it > with order, or even consolidate all the outputs into a single > structure.") But I think that may be a clean-up thing we do next round. > > The first quote above isn't 100% clear, so I can see why you might think > he meant not to expose SVE directly. Indeed you split it up exactly like it was meant: No new, redundant hook is a requirement in my view, and consolidating the multitude of parameters would be a (rather desirable) cleanup. Jan