>
>
> >> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> >> index 5635603..22819c5 100644
> >> --- a/xen/arch/x86/vm_event.c
> >> +++ b/xen/arch/x86/vm_event.c
> >> @@ -20,6 +20,7 @@
> >>
> >> #include <xen/sched.h>
> >> #include <asm/hvm/hvm.h>
> >> +#include <asm/monitor.h>
> >> #include <asm/vm_event.h>
> >>
> >> /* Implicitly serialized by the domctl lock. */
> >> @@ -27,6 +28,11 @@ int vm_event_init_domain(struct domain *d)
> >> {
> >> struct vcpu *v;
> >>
> >> + d->arch.monitor_msr_bitmap = xzalloc(struct monitor_msr_bitmap);
> >> +
> >> + if ( !d->arch.monitor_msr_bitmap )
> >> + return -ENOMEM;
> >
> > Shouldn't we in principle have a monitor_domain_init() function for
> > this, or are monitor and vm_event too intertwined in practice?
>
> I think they are (it doesn't really make sense to try to monitor MSR
> writes without initializing the vm_event subsystem). Maybe Tamas has
> different ideas?
>
There is certainly dependency between the two, but it's entirely possible
to use vm_event without the monitor subsystem (like for mem_paging and
mem_sharing). So +1 for making a monitor_domain_init that get's called only
when enabling the MONITOR ring (XEN_DOMCTL_VM_EVENT_OP_MONITOR).
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
