[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is used
> -----Original Message----- > From: Tian, Kevin > Sent: Tuesday, November 24, 2015 3:45 PM > To: Wu, Feng <feng.wu@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxx > Cc: Zhang, Yang Z <yang.z.zhang@xxxxxxxxx>; Keir Fraser <keir@xxxxxxx>; Jan > Beulich <jbeulich@xxxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > 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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |