From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V3 1/3] xen/mem_access: Support for memory-content hiding Date: Tue, 7 Jul 2015 15:33:16 +0300 Message-ID: <559BC70C.8080609@bitdefender.com> References: <1436197873-4559-1-git-send-email-rcojocaru@bitdefender.com> <1436197873-4559-2-git-send-email-rcojocaru@bitdefender.com> <559AC880.3070406@bitdefender.com> <559B8989.3030001@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: "Lengyel, Tamas" Cc: Jun Nakajima , Wei Liu , kevin.tian@intel.com, keir@xen.org, Ian Campbell , Stefano Stabellini , George Dunlap , Andrew Cooper , eddie.dong@intel.com, Xen-devel , Aravind.Gopalakrishnan@amd.com, Jan Beulich , suravee.suthikulpanit@amd.com, boris.ostrovsky@oracle.com, Ian Jackson List-Id: xen-devel@lists.xenproject.org On 07/07/2015 03:04 PM, Lengyel, Tamas wrote: > > > On Tue, Jul 7, 2015 at 4:10 AM, Razvan Cojocaru > > 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