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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.07.15 at 09:34, <feng.wu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Friday, July 24, 2015 11:28 PM
>> >>> On 23.07.15 at 13:35, <feng.wu@xxxxxxxxx> wrote:
>> > +    GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index,
>> iremap_entries, p);
>> > +
>> > +    old_ire = new_ire = *p;
>> > +
>> > +    /* Setup/Update interrupt remapping table entry. */
>> > +    setup_posted_irte(&new_ire, pi_desc, gvec);
>> > +    ret = cmpxchg16b(p, &old_ire, &new_ire);
>> > +
>> > +    ASSERT(ret == *(__uint128_t *)&old_ire);
>> > +
>> > +    iommu_flush_cache_entry(p, sizeof(struct iremap_entry));
>> 
>> sizeof(*p) please.
>> 
>> > +    iommu_flush_iec_index(iommu, 0, remap_index);
>> > +
>> > +    if ( iremap_entries )
>> > +        unmap_vtd_domain_page(iremap_entries);
>> 
>> The conditional comes way too late: Either GET_IREMAP_ENTRY()
>> can produce NULL, in which case you're hosed above. Or it can't,
>> in which case the check here is pointless.
> 
> I cannot find the case GET_IREMAP_ENTRY() produce NULL for
> "iremap_entries",

And I didn't say it would - I simply listed both possibilities and their
respective consequences for your code.

> if it is, GET_IREMAP_ENTRY() itself will get
> a big problem, right? So this check is not needed, maybe I can
> add an ASSERT() after GET_IREMAP_ENTRY().

You might, but iirc no other uses do so, so you could as well omit
any such checks.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel