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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
