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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Xu, Quan
> Sent: Monday, May 16, 2016 11:26 PM
> 
> On May 13, 2016 11:28 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > >>> On 22.04.16 at 12:54, <quan.xu@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel