[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: Tuesday, October 27, 2015 5:52 PM > To: Wu, Feng <feng.wu@xxxxxxxxx> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Dario Faggioli > <dario.faggioli@xxxxxxxxxx>; GeorgeDunlap <george.dunlap@xxxxxxxxxxxxx>; > Tian, Kevin <kevin.tian@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxx; Keir Fraser > <keir@xxxxxxx> > Subject: RE: [Xen-devel] [PATCH v8 15/17] vmx: VT-d posted-interrupt core > logic > handling > > >>> On 27.10.15 at 06:19, <feng.wu@xxxxxxxxx> wrote: > >> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx] > >> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |