>>> On 19.05.16 at 13:26, <quan...@intel.com> wrote: > On May 19, 2016 2:13 PM, Jan Beulich <jbeul...@suse.com> wrote: >> >>> "Xu, Quan" <quan...@intel.com> 05/19/16 3:35 AM >>> >> >On May 19, 2016 8:33 AM, Tian, Kevin <kevin.t...@intel.com> 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@lists.xen.org http://lists.xen.org/xen-devel