> From: Wu, Feng > Sent: Tuesday, November 24, 2015 3:54 PM > > > > -----Original Message----- > > From: Tian, Kevin > > Sent: Tuesday, November 24, 2015 3:45 PM > > To: Wu, Feng <feng...@intel.com>; xen-devel@lists.xen.org > > Cc: Zhang, Yang Z <yang.z.zh...@intel.com>; Keir Fraser <k...@xen.org>; Jan > > Beulich <jbeul...@suse.com>; Andrew Cooper <andrew.coop...@citrix.com> > > Subject: RE: [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is > > used > > > > > + > > > + iommu = drhd->iommu; > > > + ir_ctrl = iommu_ir_ctrl(iommu); > > > + if ( !ir_ctrl ) > > > + return -ENODEV; > > > + > > > + spin_lock_irq(&ir_ctrl->iremap_lock); > > > + > > > + GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, > > iremap_entries, p); > > > + > > > + old_ire = *p; > > > + > > > + /* Setup/Update interrupt remapping table entry. */ > > > + setup_posted_irte(&new_ire, &old_ire, pi_desc, gvec); > > > + ret = cmpxchg16b(p, &old_ire, &new_ire); > > > + > > > + /* > > > + * In the above, we use cmpxchg16 to atomically update the 128-bit > > IRTE, > > > + * and the hardware cannot update the IRTE behind us, so the return > > value > > > > hardware can DEFINITELY update IRTE behind us, right? e.g. after the IRTE > > entry > > is fully up, when interrupt is posted, etc. Here you might mean hardware > > cannot > > update the IRTE at this point? > > Yes, you description above is more accurate. But why hardware needs to > update IRTE when interrupt is posted? I think it needs to update the > posted interrupt descriptor when posting an interrupt, not the IRTE, > right? >
sorry mess IRTE and posted descriptor together. but using "behind" is still not accurate to state your point here. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
