From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event Date: Tue, 02 Jun 2015 19:03:24 +0300 Message-ID: <556DD3CC.7040600@bitdefender.com> References: <1432907159-21899-1-git-send-email-rcojocaru@bitdefender.com> <1433259579.15036.327.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1433259579.15036.327.camel@citrix.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: Ian Campbell Cc: kevin.tian@intel.com, keir@xen.org, jun.nakajima@intel.com, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org, eddie.dong@intel.com, jbeulich@suse.com, andrew.cooper3@citrix.com, wei.liu2@citrix.com List-Id: xen-devel@lists.xenproject.org On 06/02/2015 06:39 PM, Ian Campbell wrote: > On Fri, 2015-05-29 at 16:45 +0300, Razvan Cojocaru wrote: >> As suggested by Andrew Cooper, this patch attempts to remove >> some redundancy and allow for an easier time when adding vm_events >> for new control registers in the future, by having a single >> VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0, >> CR3, CR4 and (newly introduced) XCR0. The actual control register >> will be deduced by the new .index field in vm_event_write_ctrlreg >> (renamed from vm_event_mov_to_cr). The patch has also modified >> the xen-access.c test - it is now able to log CR3 events. >> >> Signed-off-by: Razvan Cojocaru >> Acked-by: Jan Beulich > > Seems ok from the tools and arm side, so long as the xen-access.c test > is likely to build on ARM despite the new x86-isms (it looks like it to > me) and the following Q: I think it should compile (though of course no events will be delivered), but I'm also happy to drop the xen-access.c patch completely. It's just been useful for me as a test and I thought it might be helpful for somebody else, but certainly it's not required. It would seem to be the simplest solution, the #ifdeffery for future ARM events is probably not worth it. Thanks, Razvan