All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: "Lengyel, Tamas" <tlengyel@novetta.com>
Cc: Jun Nakajima <jun.nakajima@intel.com>,
	Wei Liu <wei.liu2@citrix.com>,
	kevin.tian@intel.com, keir@xen.org,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	eddie.dong@intel.com, Xen-devel <xen-devel@lists.xen.org>,
	Aravind.Gopalakrishnan@amd.com, Jan Beulich <jbeulich@suse.com>,
	suravee.suthikulpanit@amd.com, boris.ostrovsky@oracle.com,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [PATCH V3 1/3] xen/mem_access: Support for memory-content hiding
Date: Tue, 7 Jul 2015 15:33:16 +0300	[thread overview]
Message-ID: <559BC70C.8080609@bitdefender.com> (raw)
In-Reply-To: <CAD33N+4kN7tiSK8gEePikZcpVL2FqxwsTJDLzfmVbQ3zZr9F7A@mail.gmail.com>

On 07/07/2015 03:04 PM, Lengyel, Tamas wrote:
> 
> 
> On Tue, Jul 7, 2015 at 4:10 AM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
> 
>     On 07/06/2015 09:30 PM, Lengyel, Tamas wrote:
>     >     If you'd prefer that I do some ground work for the future
>     (i.e. rename
>     >     MEM_ACCESS constants, etc.), please let me know.
>     >
>     >
>     > Yeap, that sounds reasonable to me.
> 
>     Any objections to this renaming?
> 
>     151 #define MEM_ACCESS_EMULATE_NOWRITE       (1 << 7)
>     152 /*
>     153  * Data is being sent back to the hypervisor in the event response,
>     to be
>     154  * returned by the read function when emulating an instruction.
>     155  * This flag is only useful when combined with MEM_ACCESS_EMULATE or
>     156  * MEM_ACCESS_EMULATE_NOWRITE.
>     157  * The flag has been defined here because it is used with mem_access
>     158  * events, and so should not accidentaly overwrite one of the above.
>     159  */
>     160 #define VM_EVENT_FLAG_SET_EMUL_READ_DATA (1 << 8)
> 
>     Are there any other small changes you'd like to see in this patch?
> 
> 
> That should suffice - with the flag being move to the VM_EVENT_FLAG list
> and the bitshift adjusted accordingly.

Right, sorry about that, that flag really doesn't have to care about
what the last MEM_ACCESS_ flag bit shift is, since that's only specific
to the mem_access event. For some obviously unexplainable reason I had
been convinced that there's some corner case where that matters but
that's cleary not true.


Thanks,
Razvan

  reply	other threads:[~2015-07-07 12:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 15:51 [PATCH V3 0/3] Vm_event memory introspection helpers Razvan Cojocaru
2015-07-06 15:51 ` [PATCH V3 1/3] xen/mem_access: Support for memory-content hiding Razvan Cojocaru
2015-07-06 16:50   ` Lengyel, Tamas
2015-07-06 18:27     ` Razvan Cojocaru
2015-07-06 18:30       ` Lengyel, Tamas
2015-07-07  8:10         ` Razvan Cojocaru
2015-07-07 12:04           ` Lengyel, Tamas
2015-07-07 12:33             ` Razvan Cojocaru [this message]
2015-07-07 13:09             ` Razvan Cojocaru
2015-07-07 13:15               ` Lengyel, Tamas
2015-07-07 13:21                 ` Razvan Cojocaru
2015-07-07 13:27                   ` Lengyel, Tamas
2015-07-07 10:51   ` George Dunlap
2015-07-07 13:27   ` Jan Beulich
2015-07-07 15:32     ` Razvan Cojocaru
2015-07-07 15:40       ` Jan Beulich
2015-07-07 16:20         ` Razvan Cojocaru
2015-07-07 16:24           ` Jan Beulich
2015-07-06 15:51 ` [PATCH V3 2/3] xen/vm_event: Support for guest-requested events Razvan Cojocaru
2015-07-06 16:55   ` Lengyel, Tamas
2015-07-06 17:57   ` Wei Liu
2015-07-07 11:01   ` George Dunlap
2015-07-07 11:59     ` Razvan Cojocaru
2015-07-07 13:30   ` Jan Beulich
2015-07-07 14:26     ` Daniel De Graaf
2015-07-06 15:51 ` [PATCH V3 3/3] xen/vm_event: Deny register writes if refused by vm_event reply Razvan Cojocaru
2015-07-06 17:05   ` Lengyel, Tamas
2015-07-06 17:16     ` Razvan Cojocaru
2015-07-07  9:06     ` Razvan Cojocaru
2015-07-07 12:55       ` Lengyel, Tamas
2015-07-07 13:21         ` Razvan Cojocaru
2015-07-07 13:26           ` Lengyel, Tamas
2015-07-07 11:05   ` George Dunlap
2015-07-07 13:42   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559BC70C.8080609@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tlengyel@novetta.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.