Re: [Xen-devel] [PATCH RFC V5 3/5] xen: Force-enable relevant MSR events; optimize the number of sent MSR events

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.08.14 at 16:47, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 08/08/2014 05:34 PM, Jan Beulich wrote:
>>>>> On 06.08.14 at 17:58, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> @@ -695,11 +696,30 @@ static void vmx_set_host_env(struct vcpu *v)
>>>  void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
>>>  {
>>>      unsigned long *msr_bitmap = v->arch.hvm_vmx.msr_bitmap;
>>> +    struct domain *d = v->domain;
>>>  
>>>      /* VMX MSR bitmap supported? */
>>>      if ( msr_bitmap == NULL )
>>>          return;
>>>  
>>> +    if ( mem_event_check_ring(&d->mem_event->access) )
>>> +    {
>>> +        /* Filter out MSR-s needed for memory introspection */
>> 
>> I continue to be unconvinced that this code block's surrounding
>> conditional is as precise as possible: Your introspection code
>> surely isn't the only mem-event based mechanism. Yet you'd
>> impact guests in all other cases too.
> 
> I agree, however I can't think of a way to be more specific without
> introducing a special new parameter / bit when enabling mem_access.
> If you feel that that would not be a problem, I'll add one.

I don't think it would cause a problem, but the mm/ maintainers
would be a better contact in that regard.

>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -1682,6 +1682,22 @@ void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
>>>          *eax |= XEN_HVM_CPUID_X2APIC_VIRT;
>>>  }
>>>  
>>> +static void vmx_enable_intro_msr_interception(struct domain *d)
>> 
>> The "intro" in the name is surely odd: For one, it implies that _only_
>> introspection might be interested in doing this. And then it may
>> (without reading the comments inside the function) well be an
>> abbreviation for something else, e.g. "introduction".
> 
> It's no problem to either drop "intro" or expand it into
> "introspection". Would one be preferable to the other?

Neither seems very desirable. While I can suggest one, I think a
more generic term (collectively applicable to the group of MSRs)
would be needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel