On Tue, Sep 23, 2014 at 4:00 PM, Razvan Cojocaru wrote: > On 09/23/2014 04:32 PM, Jan Beulich wrote: > >>>> On 23.09.14 at 15:14, wrote: > >> --- a/xen/common/mem_event.c > >> +++ b/xen/common/mem_event.c > >> @@ -623,12 +623,9 @@ int mem_event_domctl(struct domain *d, > >> xen_domctl_mem_event_op_t *mec, > >> HVM_PARAM_ACCESS_RING_PFN, > >> mem_access_notification); > >> > >> - if ( mec->op != XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE && > >> - rc == 0 && hvm_funcs.enable_msr_exit_interception ) > >> - { > >> - d->arch.hvm_domain.introspection_enabled = 1; > >> - hvm_funcs.enable_msr_exit_interception(d); > >> - } > >> + if ( !rc && mec->op != > XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE ) > >> + p2m_enable_msr_exit_interception(d); > > > > The name is clearly not suitable for an abstraction - there's certainly > > not going to be MSRs on each and every CPU architecture. Maybe > > consult with Razvan on an agreeable more suitable name. > > P2m_set_up_introspection() perhaps? With the MSR HVM code where > applicable, nothing (or something else) where not? Would this be too > generic? > > Yes, I think its too generic of a name (which IMHO applies to the boolean on the hvm_domain as well, introspection_enabled). I don't know what would be an adequate name for this really. Tamas > > Regards, > Razvan Cojocaru > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >