From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] evtchn: simplify sending of notifications Date: Mon, 12 Jan 2015 11:33:15 +0000 Message-ID: <54B3B0FB.7050209@citrix.com> References: <54B39A7C020000780005382E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8790472668678584147==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YAdFl-00006z-RX for xen-devel@lists.xenproject.org; Mon, 12 Jan 2015 11:33:49 +0000 In-Reply-To: <54B39A7C020000780005382E@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: Ian Campbell , Ian Jackson , Keir Fraser , Tim Deegan List-Id: xen-devel@lists.xenproject.org --===============8790472668678584147== Content-Type: multipart/alternative; boundary="------------050601000605090108010201" --------------050601000605090108010201 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable On 12/01/15 08:57, Jan Beulich wrote: > --- a/xen/include/xen/event.h > +++ b/xen/include/xen/event.h > @@ -152,10 +152,11 @@ static inline void evtchn_port_init(stru > d->evtchn_port_ops->init(d, evtchn); > } > =20 > -static inline void evtchn_port_set_pending(struct vcpu *v, > +static inline void evtchn_port_set_pending(struct domain *d, > + unsigned int vcpu_id, > struct evtchn *evtchn) I would rename this to the, now vacant, evtchn_set_pending(). It takes an evtchn* not a port. (Its sole caller was evtchn_set_pending(), so the patch won't grow) Furthermore, all callers except send_guest_vcpu_virq() currently use evtchn->notify_vcpu_id to get a struct vcpu* to pass. I think you can drop the vcpu_id parameter and use evtchn->notify_vcpu_id directly, which reduces the likelyhood of a bug where the evtchn is bound to one vcpu but a caller gets the wrong id and raises the event channel on the wrong vcpu. ~Andrew > { > - v->domain->evtchn_port_ops->set_pending(v, evtchn); > + d->evtchn_port_ops->set_pending(d->vcpu[vcpu_id], evtchn); > } > =20 > static inline void evtchn_port_clear_pending(struct domain *d, > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------050601000605090108010201 Content-Type: text/html; charset="windows-1252" Content-Length: 2302 Content-Transfer-Encoding: quoted-printable
On 12/01/15 08:57, Jan Beulich wrote:
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -152,10 +152,11 @@ static inline void evtchn_port_init(stru
         d->evtchn_port_ops->init(d, evtchn);
 }
 
-static inline void evtchn_port_set_pending(struct vcpu *v,
+static inline void evtchn_port_set_pending(struct domain *d,
+                                           unsigned int vcpu_id,
                                            struct evtchn *evtchn)

I would rename this to the, now vacant, evtchn_set_pending().=A0 It takes an evtchn* not a port.=A0 (Its sole caller was evtchn_set_pending(), so the patch won't grow)

Furthermore, all callers except send_guest_vcpu_virq() currently use evtchn->notify_vcpu_id to get a struct vcpu* to pass.=A0 I think you can drop the vcpu_id parameter and use evtchn->notify_vcpu_id directly, which reduces the likelyhood of a bug where the evtchn is bound to one vcpu but a caller gets the wrong id and raises the event channel on the wrong vcpu.

~Andrew

 {
-    v->domain->evtchn_port_ops->set_pending(v, evtchn);
+    d->evtchn_port_ops->set_pending(d->vcpu[vcpu_id], evtchn);
 }
 
 static inline void evtchn_port_clear_pending(struct domain *d,





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

--------------050601000605090108010201-- --===============8790472668678584147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8790472668678584147==--