[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> "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). 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.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.