> -----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? Thanks, Feng _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
