From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Blocking CR and MSR writes via mem_access? Date: Tue, 7 Oct 2014 13:49:33 +0100 Message-ID: <5433E15D.9060605@citrix.com> References: <542D2DA7.1060903@bitdefender.com> <542E98A1.5070706@citrix.com> <5432A674.7000205@bitdefender.com> <5433BEB3.2070300@bitdefender.com> <5433C4E7.5040102@bitdefender.com> <5433FB41020000780003CDBA@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5533974414135802434==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel , Jan Beulich Cc: Razvan Cojocaru , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============5533974414135802434== Content-Type: multipart/alternative; boundary="------------060002000008080903050706" --------------060002000008080903050706 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 07/10/14 13:46, Tamas K Lengyel wrote: > > > On Tue, Oct 7, 2014 at 2:40 PM, Jan Beulich > wrote: > > >>> On 07.10.14 at 14:30, > wrote: > > IMHO that entire struct is in dire need of a cleanup. It is > really hacky to > > have fields like gla and gfn transfer values that mean different > things > > under different event type that don't have anything to do with > gla/gfn. > > It's sort of just a legacy struct from the time when we only had > EPT events > > and everything else just got hacked on top. I would be in favor > of having > > the struct as a union of substructs that nicely define all the > values that > > are transferred in the given context, with meaningful struct > member names. > > And the whole thing isn't just "mem-event" anymore either ... > > Jan > > > And that as well =) The whole mem_access and mem_event distinction is > also pretty blurry. Might worth coming up with a better name while > also combining the two into something more consistent.. xen-events > perhaps? > > Tamas > The "xen" ought to be explicit given the prefix on the hypercalls. "vm-events" as a name? ~Andrew --------------060002000008080903050706 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 07/10/14 13:46, Tamas K Lengyel wrote:


On Tue, Oct 7, 2014 at 2:40 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 07.10.14 at 14:30, <tamas.lengyel@zentific.com> wrote:
> IMHO that entire struct is in dire need of a cleanup. It is really hacky to
> have fields like gla and gfn transfer values that mean different things
> under different event type that don't have anything to do with gla/gfn.
> It's sort of just a legacy struct from the time when we only had EPT events
> and everything else just got hacked on top. I would be in favor of having
> the struct as a union of substructs that nicely define all the values that
> are transferred in the given context, with meaningful struct member names.

And the whole thing isn't just "mem-event" anymore either ...

Jan

And that as well =) The whole mem_access and mem_event distinction is also pretty blurry. Might worth coming up with a better name while also combining the two into something more consistent.. xen-events perhaps?

Tamas


The "xen" ought to be explicit given the prefix on the hypercalls.  "vm-events" as a name?

~Andrew
--------------060002000008080903050706-- --===============5533974414135802434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5533974414135802434==--