From: "Xu, Quan" <quan.xu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "dario.faggioli@citrix.com" <dario.faggioli@citrix.com>,
"Wu, Feng" <feng.wu@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v9 1/3] VT-d: add a command line parameter for Queued Invalidation
Date: Thu, 7 Apr 2016 01:49:04 +0000 [thread overview]
Message-ID: <945CA011AD5F084CBEA3E851C0AB28894B878A2F@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <57039CE902000078000E3128@prv-mh.provo.novell.com>
On April 05, 2016 5:09pm, <JBeulich@suse.com> wrote:
> >>> On 01.04.16 at 16:47, <quan.xu@intel.com> wrote:
>
> The subject should mention "timeout", perhaps either in addition to or in place
> of "command line".
>
I prefer "VT-d: add a timeout parameter for Queued Invalidation".
> > --- 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.
Agreed.
>
> > +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.
>
Could I drop it?
> > +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.)
Yes, no specific reason.
Also there's no reason the spell out the command line option again
> here - the context makes clear which value needs increasing.
>
Agreed.
Then, the new description of xen-command-line.markdown:
+### 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.
+
Any more suggestion?
Quan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-07 1:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 14:47 [PATCH v9 0/3] VT-d Device-TLB flush issue Quan Xu
2016-04-01 14:47 ` [PATCH v9 1/3] VT-d: add a command line parameter for Queued Invalidation Quan Xu
2016-04-05 9:09 ` Jan Beulich
2016-04-07 1:49 ` Xu, Quan [this message]
2016-04-07 1:51 ` Tian, Kevin
2016-04-01 14:47 ` [PATCH v9 2/3] VT-d: wrap a _sync version for all VT-d flush interfaces Quan Xu
2016-04-05 9:35 ` Jan Beulich
2016-04-07 7:44 ` Xu, Quan
2016-04-07 15:28 ` Jan Beulich
2016-04-08 2:20 ` Xu, Quan
2016-04-11 7:25 ` Tian, Kevin
2016-04-11 9:07 ` Xu, Quan
2016-04-11 6:52 ` Tian, Kevin
2016-04-11 8:01 ` Xu, Quan
2016-04-01 14:47 ` [PATCH v9 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue Quan Xu
2016-04-05 9:47 ` Jan Beulich
2016-04-10 14:28 ` Xu, Quan
2016-04-11 16:17 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=945CA011AD5F084CBEA3E851C0AB28894B878A2F@SHSMSX101.ccr.corp.intel.com \
--to=quan.xu@intel.com \
--cc=JBeulich@suse.com \
--cc=dario.faggioli@citrix.com \
--cc=feng.wu@intel.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).