From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v3 1/2] x86/mem_event: Deliver gla fault EPT violation information Date: Fri, 8 Aug 2014 10:02:17 +0100 Message-ID: <53E49219.8070602@citrix.com> References: <1407453172-10785-1-git-send-email-tamas.lengyel@zentific.com> <53E4919B020000780002A504@mail.emea.novell.com> <53E48496.503@citrix.com> <53E4ACFC020000780002A7BD@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XFg46-0000CS-Vt for xen-devel@lists.xenproject.org; Fri, 08 Aug 2014 09:02:23 +0000 In-Reply-To: <53E4ACFC020000780002A7BD@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 , Tamas Lengyel Cc: kevin.tian@intel.com, Ian Campbell , Stefano Stabellini , Jun Nakajima , eddie.dong@intel.com, Ian Jackson , Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com, "xen-devel@lists.xenproject.org" , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 08/08/14 09:57, Jan Beulich wrote: >>>> On 08.08.14 at 10:36, wrote: >> I actually disagree here because there is still a slight difference between >> the Intel and AMD implementation. In Intel's case gla_fault is only >> available iff gla_valid is set. AMD doesn't have gla_valid. So in the >> abstracted code, having gla_fault 0 could mean potentially different >> things. That's certainly not good for abstraction. The AMD side could set >> gla_valid = 1 if either if their two-bits that we will aggregate into >> gla_fault is set, but without actually providing a gla.. and that could >> lead to its own set of problems. So if we want to keep the bit aggregated >> in gla_fault, we would need a bool_t gla_fault_valid.... which is just >> going back to square one of having two bool_t fields as this patch does >> already. > Hmm, the question is of what use the fault kind is when you don't > get passed the GLA. I.e. part of the problem may be a naming one: > "gla_fault" clearly implies a connection to there being a GLA. > > Jan > I made the assumption that "gla_fault" was more "linear fault information valid", and it does appear to be used that way in the current code. Renaming it might be hard, as it is now in the public API, but a clarifying comment in public/mem_event.h might not go amiss. ~Andrew