xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

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