From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wu, Feng" Subject: Re: [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling Date: Wed, 28 Oct 2015 02:58:33 +0000 Message-ID: References: <1444640103-4685-1-git-send-email-feng.wu@intel.com> <1444640103-4685-16-git-send-email-feng.wu@intel.com> <1445870370.2717.103.camel@citrix.com> <562F574A02000078000AEFC7@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <562F574A02000078000AEFC7@prv-mh.provo.novell.com> Content-Language: en-US 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 Cc: "Tian, Kevin" , Keir Fraser , GeorgeDunlap , Andrew Cooper , Dario Faggioli , "xen-devel@lists.xen.org" , "Wu, Feng" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, October 27, 2015 5:52 PM > To: Wu, Feng > Cc: Andrew Cooper ; Dario Faggioli > ; GeorgeDunlap ; > Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser > > Subject: RE: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic > handling > > >>> On 27.10.15 at 06:19, wrote: > >> From: Dario Faggioli [mailto:dario.faggioli@citrix.com] > >> Sent: Monday, October 26, 2015 10:40 PM > >> In any case, it would have been nice, given the situation, if you'd have put a > few > >> words about, e.g., which solution you ended up implementing and why, > either in > >> the cover or here (e.g., in the '---' area). > > > > Thanks for the suggestion. As I mentioned before, updating the PI descriptor > > needs > > to be atomic, I think it should be a little expensive. So doing it every > > VM-exit seems > > not a good idea to me. > > You could check whether any update is needed before doing the > (atomic) cmpxchg16b. I am not sure why you mentioned (atomic) cmpxchg16b here, for atomically Update PI descriptor, we don't need use cmpxchg16b, right? In my understanding, It seems there were two suggestions about this: #1: Set 'SN' on each VM-Exit and clear 'SN' on each VM-Entry, so we don't need to care about the status of 'SN' in root mode. This is what I mean "not a good idea", since we add an atomic operation on each VM-Exit/VM-Entry. #2: For the blocking cancel case, let's take the following code for example: void vcpu_block(void) { struct vcpu *v = current; set_bit(_VPF_blocked, &v->pause_flags); arch_vcpu_block(v); /* Check for events /after/ blocking: avoids wakeup waiting race. */ if ( local_events_need_delivery() ) { clear_bit(_VPF_blocked, &v->pause_flags); /* arch_vcpu_block_cancel(v); */ } else { TRACE_2D(TRC_SCHED_BLOCK, v->domain->domain_id, v->vcpu_id); raise_softirq(SCHEDULE_SOFTIRQ); } } We still call arch_vcpu_block() in vcpu_block(), but we don't need to call arch_vcpu_block_cancel(v) when local_events_need_delivery() returns true. Then before VM-Entry, we can check if 'NV' field is ' pi_wakeup_vector', if it is, we change the PI status and remove it from the blocking list. Jan, if #2 is what you mean, I think it worth a try. If I don't understand your comments correctly, could you please elaborate it more? Thanks a lot! Thanks, Feng