Re: [Xen-devel] [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is used

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----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