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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/07/15 17:00, Jan Beulich wrote:
>>>> On 23.07.15 at 17:55, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 23/07/15 16:52, Jan Beulich wrote:
>>>>>> On 23.07.15 at 15:51, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 23/07/15 12:35, Feng Wu 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);
>>>> This cannot be correct.  Either the cmpxchg() is required and you must
>>>> cope with it failing, or the cmpxchg() is not required and this should
>>>> be a plain write.
>>> Not exactly: The cmpxchg() is required for this to be an atomic
>>> 128-bit write. And hence I would view the ASSERT() as
>>> appropriate - it validates that the entry didn't change behind our
>>> back.
>> But p is an active descriptor, which means hardware is liable to change
>> it behind our back.
> I inquired about this on the previous round and was told
> hardware doesn't alter the descriptor.

Ah - apologies for not noticing this.

> Comparing this with
> the spec, I couldn't spot any fields that I would suspect
> getting written. Which fields do you have in mind?

None in particular.

I called it out because ASSERT(cmpxchg(...) == old) reads as if it is buggy.

If hardware will genuinely never update the descriptor, then a comment
should be put in here explaining why the assert is safe in this instance.

~Andrew

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