[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 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)?

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

Quan


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