On Mon, Mar 20, 2017 at 06:50:37AM -0600, Jan Beulich wrote: >>>> On 20.03.17 at 06:22, <chao....@intel.com> wrote: >> On Mon, Mar 20, 2017 at 04:26:10AM -0600, Jan Beulich wrote: >>>>>> On 20.03.17 at 03:38, <chao....@intel.com> 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@lists.xen.org https://lists.xen.org/xen-devel