[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI
On Mon, Mar 20, 2017 at 06:50:37AM -0600, Jan Beulich wrote: >>>> On 20.03.17 at 06:22, <chao.gao@xxxxxxxxx> wrote: >> On Mon, Mar 20, 2017 at 04:26:10AM -0600, Jan Beulich wrote: >>>>>> On 20.03.17 at 03:38, <chao.gao@xxxxxxxxx> wrote: >>>> On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich wrote: >>>>>>>> spin_unlock(&d->event_lock); >>>>>>>> if ( dest_vcpu_id >= 0 ) >>>>>>>> hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]); >>> >>>... right after the lock release. >> >> @via_pi is also consumed during vCPU migration. > >But the event lock isn't being held around the checking of the >field, so putting the setting of the field under lock is of no use. > >> I just think the event_lock protects R/W operations on struct hvm_pirq_dpci. >> To prohibit potential race(we can't use VT-d PI in 1st binding, but we can >> use >> in the 2nd binding. But somehow the first update to via_pi overrides the >> second one), >> and don't complicate the fields event_lock protects, >> I'm inclined to put it in event_lock-ed region as long as it doesn't >> introduce other issues. > >I certainly don't object to properly synchronizing things here, >but then both producing and consuming side need to hold >respective locks. Otherwise the best you can hope for is to >reduce timing windows; you won't eliminate them though. You are right. I am convinced. Thanks Chao > >Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |