From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed White Subject: Re: [PATCH v2 07/12] x86/altp2m: add control of suppress_ve. Date: Thu, 25 Jun 2015 09:36:21 -0700 Message-ID: <558C2E05.3040300@intel.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558BD42502000078000895BD@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich 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/25/2015 01:12 AM, Jan Beulich wrote: >>>> On 24.06.15 at 19:53, wrote: >> On 06/24/2015 07:38 AM, Jan Beulich wrote: >>>>>> On 22.06.15 at 20:56, wrote: >>>> --- a/xen/include/asm-x86/p2m.h >>>> +++ b/xen/include/asm-x86/p2m.h >>>> @@ -237,6 +237,19 @@ struct p2m_domain { >>>> p2m_access_t *p2ma, >>>> p2m_query_t q, >>>> unsigned int *page_order); >>>> + int (*set_entry_full)(struct p2m_domain *p2m, >>>> + unsigned long gfn, >>>> + mfn_t mfn, unsigned int >> page_order, >>>> + p2m_type_t p2mt, >>>> + p2m_access_t p2ma, >>>> + unsigned int sve); >>>> + mfn_t (*get_entry_full)(struct p2m_domain *p2m, >>>> + unsigned long gfn, >>>> + p2m_type_t *p2mt, >>>> + p2m_access_t *p2ma, >>>> + p2m_query_t q, >>>> + unsigned int *page_order, >>>> + unsigned int *sve); >>> >>> I have to admit that I find the _full suffixes here pretty odd. Based >>> on the functionality, they should be _sve. 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. >> >> I did originally use _sve suffixes. I changed them because there >> may be some future case where these routines control some other >> EPTE bit too. I made them hooks because I thought calling ept... >> functions directly would be a layering violation. > > Indeed it would. But thinking about it more, I would suggest to > extend the existing accessors rather than adding new ones. > Just consider what would result when further such return values > are going to be needed in the future: I don't see us adding > _fuller, _fullest, etc variants. Perhaps just make the new output > an optional generic "flags" one. One might even consider folding > it with order, or even consolidate all the outputs into a single > structure. The new functions are called in 3 places only, so changing them later would have minimal impact. The existing functions are called in many, many places. I *really* don't want to go changing the amount of existing code that doing what you suggest would entail at this late stage. Ed