Re: [Xen-devel] [PATCH 1/2] x86/monitor: Introduce a boolean to suppress nested monitoring events

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/10/18 15:54, Razvan Cojocaru wrote:
> On 10/23/18 5:35 PM, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
>> index 2a41ccc..f1a196f 100644
>> --- a/xen/arch/x86/hvm/monitor.c
>> +++ b/xen/arch/x86/hvm/monitor.c
>> @@ -36,6 +36,9 @@ bool hvm_monitor_cr(unsigned int index, unsigned long 
>> value, unsigned long old)
>>      struct arch_domain *ad = &curr->domain->arch;
>>      unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
>>  
>> +    if ( curr->monitor.suppress )
>> +        return 0;
>> +
>>      if ( index == VM_EVENT_X86_CR3 && hvm_pcid_enabled(curr) )
>>          value &= ~X86_CR3_NOFLUSH; /* Clear the noflush bit. */
>>  
>> @@ -73,6 +76,9 @@ bool hvm_monitor_emul_unimplemented(void)
>>          .vcpu_id  = curr->vcpu_id,
>>      };
>>  
>> +    if ( curr->monitor.suppress )
>> +        return false;
> Rather than doing this for each event, I think we may be able to do it
> only in monitor_traps(). Am I missing something?

I guess that depends on how expensive it is to collect together the
other data being fed into the monitor ring.  I suppose it is only the
hvm_do_resume() path which will suffer, and only on a reply from
introspection, which isn't exactly a fastpath.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel