Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On 06/04/2015 10:56 PM, Jan Beulich wrote: Razvan Cojocaru rcojoc...@bitdefender.com 06/04/15 3:46 PM On 06/04/2015 04:43 PM, Tim Deegan wrote: At 14:40 +0100 on 04 Jun (1433428815), Tim Deegan wrote: At 16:45 +0300 on 29 May (1432917959), 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org Ah, I see I've acked an old version. The ack stands for v9, whough if you're going to v10, can you please rename the macro to, e,g, #define hvm_event_crX(what, new, old) \ hvm_event_cr(VM_EVENT_X86_##what, new, old) Of course, if Jan (who originally proposed the macro) doesn't have any objections, I'll rename it. While I personally think it's better the way it is now, I don't object to it being renamed, even less so considering that Tim is the maintainer of that code and hence should have the final say. Understood, in that case I'll submit V10 tomorrow with the macro renamed to hvm_event_crX() as Tim has suggested. I am assuming that, since this will be the only change, it's fine to keep all the acks. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
Razvan Cojocaru rcojoc...@bitdefender.com 06/04/15 3:46 PM On 06/04/2015 04:43 PM, Tim Deegan wrote: At 14:40 +0100 on 04 Jun (1433428815), Tim Deegan wrote: At 16:45 +0300 on 29 May (1432917959), 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org Ah, I see I've acked an old version. The ack stands for v9, whough if you're going to v10, can you please rename the macro to, e,g, #define hvm_event_crX(what, new, old) \ hvm_event_cr(VM_EVENT_X86_##what, new, old) Of course, if Jan (who originally proposed the macro) doesn't have any objections, I'll rename it. While I personally think it's better the way it is now, I don't object to it being renamed, even less so considering that Tim is the maintainer of that code and hence should have the final say. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
At 16:45 +0300 on 29 May (1432917959), 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org FWIW, I think this: +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long old); +#define hvm_event_cr(what, new, old) hvm_event_cr(VM_EVENT_X86_##what, new, old) is pretty nasty, and would prefer the function to have a different name from the macro, but I'm not going to push a v8 series out to v9 over it. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
At 14:40 +0100 on 04 Jun (1433428815), Tim Deegan wrote: At 16:45 +0300 on 29 May (1432917959), 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org Ah, I see I've acked an old version. The ack stands for v9, whough if you're going to v10, can you please rename the macro to, e,g, #define hvm_event_crX(what, new, old) \ hvm_event_cr(VM_EVENT_X86_##what, new, old) Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On 06/04/2015 04:43 PM, Tim Deegan wrote: At 14:40 +0100 on 04 Jun (1433428815), Tim Deegan wrote: At 16:45 +0300 on 29 May (1432917959), 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org Ah, I see I've acked an old version. The ack stands for v9, whough if you're going to v10, can you please rename the macro to, e,g, #define hvm_event_crX(what, new, old) \ hvm_event_cr(VM_EVENT_X86_##what, new, old) Of course, if Jan (who originally proposed the macro) doesn't have any objections, I'll rename it. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com 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: +/* Supported values for the vm_event_write_ctrlreg index. */ +#define VM_EVENT_X86_CR00 +#define VM_EVENT_X86_CR31 +#define VM_EVENT_X86_CR42 +#define VM_EVENT_X86_XCR0 3 Is the intention for different architectures to use non-overlapping number spaces? (i.e. ARM would start from 0x1 or something)? If not then the usages in xen-access.c are a little more problematic. I can just about tolerate a tool on arm which asks monitor x86 cr3 and then never sees anything, but to get events for whatever ARM reg happens to share the index instead would be wrong I think. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On 02/06/15 16:39, 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com 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: +/* Supported values for the vm_event_write_ctrlreg index. */ +#define VM_EVENT_X86_CR00 +#define VM_EVENT_X86_CR31 +#define VM_EVENT_X86_CR42 +#define VM_EVENT_X86_XCR0 3 Is the intention for different architectures to use non-overlapping number spaces? (i.e. ARM would start from 0x1 or something)? If not then the usages in xen-access.c are a little more problematic. I can just about tolerate a tool on arm which asks monitor x86 cr3 and then never sees anything, but to get events for whatever ARM reg happens to share the index instead would be wrong I think. When I suggested this, I expected each arch to maintain its own index space and for these spaces to all start at 0, as there is very little which is truly common at this level. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On Tue, 2015-06-02 at 16:43 +0100, Andrew Cooper wrote: On 02/06/15 16:39, 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 rcojoc...@bitdefender.com Acked-by: Jan Beulich jbeul...@suse.com 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: +/* Supported values for the vm_event_write_ctrlreg index. */ +#define VM_EVENT_X86_CR00 +#define VM_EVENT_X86_CR31 +#define VM_EVENT_X86_CR42 +#define VM_EVENT_X86_XCR0 3 Is the intention for different architectures to use non-overlapping number spaces? (i.e. ARM would start from 0x1 or something)? If not then the usages in xen-access.c are a little more problematic. I can just about tolerate a tool on arm which asks monitor x86 cr3 and then never sees anything, but to get events for whatever ARM reg happens to share the index instead would be wrong I think. When I suggested this, I expected each arch to maintain its own index space and for these spaces to all start at 0, as there is very little which is truly common at this level. That's fine too, but implies that tests/xen-access.c therefore needs some additional #ifdeffery. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Friday, May 29, 2015 9:46 PM
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 rcojoc...@bitdefender.com
Acked-by: Jan Beulich jbeul...@suse.com
Acked-by: Kevin Tian kevin.t...@intel.com
---
Changes since V7:
- Explicitly #include asm/hvm/event.h.
---
tools/libxc/include/xenctrl.h |9 ++---
tools/libxc/xc_monitor.c| 40 +++---
tools/tests/xen-access/xen-access.c | 30 +++--
xen/arch/x86/hvm/event.c| 55 +-
xen/arch/x86/hvm/hvm.c | 11 +++---
xen/arch/x86/hvm/vmx/vmx.c |6 ++--
xen/arch/x86/monitor.c | 63
+--
xen/include/asm-x86/domain.h| 12 ++-
xen/include/asm-x86/hvm/event.h |5 ++-
xen/include/asm-x86/monitor.h |2 ++
xen/include/public/domctl.h | 12 +++
xen/include/public/vm_event.h | 29
12 files changed, 114 insertions(+), 160 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09a7450..83fd289 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2375,12 +2375,9 @@ int xc_mem_access_disable_emulate(xc_interface
*xch, domid_t domain_id);
void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t
*port);
int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool
enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool
enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool
enable,
- bool sync, bool onchangeonly);
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly);
int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool
enable,
bool extended_capture);
int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool
enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 87ad968..63013de 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -45,8 +45,9 @@ int xc_monitor_resume(xc_interface *xch, domid_t
domain_id)
NULL);
}
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool
enable,
- bool sync, bool onchangeonly)
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly)
{
DECLARE_DOMCTL;
@@ -54,39 +55,8 @@ int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t
domain_id, bool enable,
domctl.domain = domain_id;
domctl.u.monitor_op.op = enable ?
XEN_DOMCTL_MONITOR_OP_ENABLE
:
XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event =
XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR0;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool
enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ?
XEN_DOMCTL_MONITOR_OP_ENABLE
-:
XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event =
XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR3;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool
enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ?
XEN_DOMCTL_MONITOR_OP_ENABLE
-
[Xen-devel] [PATCH V8] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
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 rcojoc...@bitdefender.com
Acked-by: Jan Beulich jbeul...@suse.com
---
Changes since V7:
- Explicitly #include asm/hvm/event.h.
---
tools/libxc/include/xenctrl.h |9 ++---
tools/libxc/xc_monitor.c| 40 +++---
tools/tests/xen-access/xen-access.c | 30 +++--
xen/arch/x86/hvm/event.c| 55 +-
xen/arch/x86/hvm/hvm.c | 11 +++---
xen/arch/x86/hvm/vmx/vmx.c |6 ++--
xen/arch/x86/monitor.c | 63 +--
xen/include/asm-x86/domain.h| 12 ++-
xen/include/asm-x86/hvm/event.h |5 ++-
xen/include/asm-x86/monitor.h |2 ++
xen/include/public/domctl.h | 12 +++
xen/include/public/vm_event.h | 29
12 files changed, 114 insertions(+), 160 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09a7450..83fd289 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2375,12 +2375,9 @@ int xc_mem_access_disable_emulate(xc_interface *xch,
domid_t domain_id);
void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly);
int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
bool extended_capture);
int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 87ad968..63013de 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -45,8 +45,9 @@ int xc_monitor_resume(xc_interface *xch, domid_t domain_id)
NULL);
}
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly)
{
DECLARE_DOMCTL;
@@ -54,39 +55,8 @@ int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t
domain_id, bool enable,
domctl.domain = domain_id;
domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR0;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
-: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR3;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
-: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR4;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG;
+domctl.u.monitor_op.u.mov_to_cr.index = index;
