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

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



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

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

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

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®.