Re: [Xen-devel] VT-d flush timeout

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-08-18:
>>>> "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> 08/18/14 4:01 AM >>>
>> After reviewing Linux IOMMU code, it uses the timeout mechanism
>> widely, e.g., flush iotlb and context via register based mechanism,
>> __iommu_flush_context():
>> /* Make sure hardware complete it */
>> IOMMU_WAIT_OP(iommu, DMAR_CCMD_REG,
>> dmar_readq, (!(val & DMA_CCMD_ICC)), val);
> 
> I don't think using Linux as a reference is valid here, especially
> when Linux behaves as wrongly as Xen currently does (spinning).
> 
>> The only place it doesn't use this timeout mechanism is queue based
>> invalidation. I think the reason is that the max number of queue
>> entry is
>> 2^15 and we don't know how much time is needed really to flush 2^15
>> entries. So it is better to not use timeout here. Likewise, for Xen
>> side, we will only remove the timeout in qi flush function and use
>> spin for
> instead.
> 
> What would that buy us? You spin either way. According what was
> discussed on our weekly calls so far, the intention for a first step
> was to reduce the current 1s timeout to a value large enough to cover
> what the IOMMU really requires (in the non-ATS cases only of course).

I don't get your point. What's the different between the 1s and the large 
enough value? Since hardware completed the flush quickly, it will never spin 
more than real flush time in normal case. 1s spin only happens in the abnormal 
case.
My only concern is that, for QI flush, the spin time relies on the length of 
the queue. I am not sure whether 1s is enough for worst case and I think we 
should remove the 1s in QI flush. And I think this also the same reason for 
Linux don't use timeout mechanism in QI flush.

> The second more involved step would then be to get rid of all the
> spinning where, as Andrew already said, the maximum time period to wait is 
> longer than a few microseconds.

Agree. In future, we must adapt more reasonable approach to do it, like 
asynchronous flush.

> 
> Jan


Best regards,
Yang



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