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 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 > Acked-by: Jan Beulich Acked-by: Tim Deegan >>> >>> 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 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 Acked-by: Jan Beulich >>> >>> Acked-by: Tim Deegan >> >> 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
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 >>> Acked-by: Jan Beulich >> >> Acked-by: Tim Deegan > > 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
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 > > Acked-by: Jan Beulich > > Acked-by: Tim Deegan 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
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 > Acked-by: Jan Beulich Acked-by: Tim Deegan 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
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 ___ 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 > >> 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: > > > >> +/* 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
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 >> 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: > >> +/* 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 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: > +/* 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
> 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
> Acked-by: Jan Beulich
Acked-by: Kevin Tian
>
> ---
> Changes since V7:
> - Explicitly #include .
> ---
> 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 = ena
[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
Acked-by: Jan Beulich
---
Changes since V7:
- Explicitly #include .
---
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;
domctl.u.monitor_op.u.mov_to_cr.sync = sync;
domc
