> From: Xu, Quan > Sent: Monday, May 16, 2016 11:26 PM > > On May 13, 2016 11:28 PM, Jan Beulich <jbeul...@suse.com> wrote: > > >>> On 22.04.16 at 12:54, <quan...@intel.com> wrote: > > > --- a/docs/misc/xen-command-line.markdown > > > +++ b/docs/misc/xen-command-line.markdown > > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also > > specified vpmu will be turned off. > > > As the virtualisation is not 100% safe, don't use the vpmu flag on > > > production systems (see http://xenbits.xen.org/xsa/advisory-163.html)! > > > > > > +### vtd\_qi\_timeout (VT-d) > > > +> `= <integer>` > > > + > > > +> Default: `1` > > > + > > > +Specify the timeout of the VT-d Queued Invalidation in milliseconds. > > > + > > > +By default, the timeout is 1ms. When you see error 'Queue invalidate > > > +wait descriptor timed out', try increasing this value. > > > > So when someone enables ATS, will the 1ms timeout apply to the dev iotlb > > invalidations too? > > Yes, > The timeout is the same for IOTLB, Context, IEC and Device-TLB invalidation. > > > If so, that's surely too short, and would ideally be adjusted > > automatically, but the need for a higher timeout in that case should in any > > event be mentioned here. > > I can try to use 1ms for IOTLB, Context and IEC invalidation. As mentioned, > 1 ms is > enough for IOTLB, Context and IEC invalidation. > What about 10 ms for Device-TLB (10 ms is just a higher timeout, no specific > meaning)?
I remember in earlier discussion we agreed to use 1ms as the default for both IOMMU-side and device-side flushes. For device-side flushes, we checked internal HW team that 1ms is a reasonable threshold for integrated devices. It's likely insufficient for discrete devices. We may check any automatic adjustment method later when it becomes a real problem. For now, please elaborate above information in the text. > > > > > Apart from that aspect this patch seems to be ready, but will clearly need > > a VT- > > d maintainer's ack. > > > > Thanks for your review. I will also test this patch against the last commit ( > I am still out > of office and I will do it around this Wednesday). > Jan, do you want me to ack this series now, or wait until previous series handling error is checked in? (I thought you wanted the later in one of your replies earlier). Either way is OK to me. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel