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
next prev parent 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.