Re: [Xen-devel] [PATCH v9 1/3] VT-d: add a command line parameter for Queued Invalidation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.04.16 at 16:47, <quan.xu@xxxxxxxxx> wrote:

The subject should mention "timeout", perhaps either in addition to or
in place of "command line".

> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1532,6 +1532,24 @@ 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 spin timeout is 1ms, which can be boot-time changed.

Especially the part after the comma makes little sense considering
which file we're in.

> +In current code, VT-d Queued Invalidation includes Device-TLB, IOTLB,
> +Context and IEC flush. If Device-TLB flush timed out, we would hide
> +the target ATS device and crash the domain owning this ATS device.
> +If impacted domain is hardware domain, just throw out a warning (done
> +in queue\_invalidate\_wait). IOTLB, Context and IEC flush timeout are
> +still in TODO-list.

Much of this doesn't seem to belong here either.

> +When you see error 'Queue invalidate wait descriptor timed out', try
> +increasing the vtd\_qi\_timeout to 10ms or more.

Why 10ms? (If there's no specific reason, I think you'd better
drop any explicit number.) Also there's no reason the spell out the
command line option again here - the context makes clear which
value needs increasing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel