All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
	Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH 1/2] x86/monitor: Introduce a boolean to suppress nested monitoring events
Date: Tue, 23 Oct 2018 18:27:48 +0300	[thread overview]
Message-ID: <3a274022-10c4-dab9-f2cf-547c24466a3a@bitdefender.com> (raw)
In-Reply-To: <9a325052-409c-d6b0-d6fe-fe685b3a6325@citrix.com>

On 10/23/18 6:08 PM, Andrew Cooper wrote:
> 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.

monitor_traps() calls vm_event_fill_regs(req); at the very end, which
you can short-circuit by returning sooner. The rest of the information I
believe has already been collected where you test v->monitor.suppress:

 91 int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req)
 92 {
 93     int rc;
 94     struct domain *d = v->domain;
 95
 96     rc = vm_event_claim_slot(d, d->vm_event_monitor);
 97     switch ( rc )
 98     {
 99     case 0:
100         break;
101     case -ENOSYS:
102         /*
103          * If there was no ring to handle the event, then
104          * simply continue executing normally.
105          */
106         return 0;
107     default:
108         return rc;
109     };
110
111     req->vcpu_id = v->vcpu_id;
112
113     if ( sync )
114     {
115         req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
116         vm_event_vcpu_pause(v);
117         rc = 1;
118     }
119
120     if ( altp2m_active(d) )
121     {
122         req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
123         req->altp2m_idx = altp2m_vcpu_idx(v);
124     }
125
126     vm_event_fill_regs(req);
127     vm_event_put_request(d, d->vm_event_monitor, req);
128
129     return rc;
130 }


Thanks,
Razvan

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

  reply	other threads:[~2018-10-23 15:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23 14:35 [PATCH 0/2] x86/monitor: More generic livelock avoidance Andrew Cooper
2018-10-23 14:35 ` [PATCH 1/2] x86/monitor: Introduce a boolean to suppress nested monitoring events Andrew Cooper
2018-10-23 14:54   ` Razvan Cojocaru
2018-10-23 15:08     ` Andrew Cooper
2018-10-23 15:27       ` Razvan Cojocaru [this message]
2018-10-23 14:35 ` [PATCH 2/2] x86/hvm: Drop the may_defer boolean from hvm_* helpers Andrew Cooper
2018-10-23 15:24   ` Razvan Cojocaru
2018-10-24 10:00     ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a274022-10c4-dab9-f2cf-547c24466a3a@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=tamas@tklengyel.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.