Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

["Xu, Quan" <quan.xu@xxxxxxxxx>]

On May 19, 2016 7:36 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>> On 19.05.16 at 13:26, <quan.xu@xxxxxxxxx> wrote:
> > On May 19, 2016 2:13 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >> >>> "Xu, Quan" <quan.xu@xxxxxxxxx> 05/19/16 3:35 AM >>>
> >> >On May 19, 2016 8:33 AM, Tian, Kevin <kevin.tian@xxxxxxxxx> wrote:
> >> >> A single default value for both IOMMU-side and device-side is
> >> >> anyway not optimal. What about introducing a new knob e.g.
> >> >> vtd_qi_device_timeout specifically for device-side flush while
> >> >> using vtd_qi_timeout for other places? If device-side timeout is
> >> >> not specified, it is
> >> then default to vtd_qi_timeout.
> >>
> >> There should imo be a single command line option, allowing for two
> >> values to be passed (e.g. comma-separated).
> >
> > As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation,
> > so we are no need to increasing the value of timeout or introduce a
> > boot-time changed parameter.
> > What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC
> > invalidation timeout.
> 
> If you're absolutely certain no-one will ever find a need to increase that 
> value -
> sure.
> 

Sure.
Also this was mentioned in Kevin's ' Revisit VT-d asynchronous flush issue ' , 
http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00041.html 

"""-For context/iotlb/iec flush, our measurements show worst cases <10us. We 
also confirmed with hardware team, that 1ms is large  enough for IOMMU internal 
flush. """

> > For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout',
> > which is boot-time changed, and 1 ms by default.
> 
> One question is whether making this a VT-d specific command line option is a
> good idea: Other IOMMU implementations ought to be in need of doing
> device IOTLB invalidation too, at least sooner or later.
> 

This is indeed farsighted. Agreed.

> The other question is whether any timeout lower than the current one can be
> considered safe (and hence is usable as a default).
> 

Actually the criticality, 1 ms, is from hardware team.
IOW, Our hardware team confirmed that 1ms should be enough for integrated PCI 
devices with ATS.
for discrete PCI devices with ATS, it's uncertain whether 1ms  or 10ms is too 
restrictive to them, but there are only a few devices now in the market.

Quan

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