xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Xu, Quan" <quan.xu@intel.com>, Jan Beulich <JBeulich@suse.com>,
	"Wu, Feng" <feng.wu@intel.com>
Cc: "dario.faggioli@citrix.com" <dario.faggioli@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v9 2/3] VT-d: wrap a _sync version for all VT-d flush interfaces
Date: Mon, 11 Apr 2016 07:25:04 +0000	[thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D15F817D3F@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28894B885C33@SHSMSX101.ccr.corp.intel.com>

> From: Xu, Quan
> Sent: Friday, April 08, 2016 10:21 AM
> 
> On April 07, 2016 11:29pm, Jan Beulich <JBeulich@suse.com> wrote:
> > >>> On 07.04.16 at 09:44, <quan.xu@intel.com> wrote:
> > > On April 05, 2016 5:35pm, Jan Beulich <JBeulich@suse.com> wrote:
> > >> >>> On 01.04.16 at 16:47, <quan.xu@intel.com> wrote:
> > >> > +{
> > >> > +    queue_invalidate_context(iommu, did, source_id,
> > >> > +                             function_mask, granu);
> > >> > +
> > >> > +    return invalidate_sync(iommu); }
> > >>
> > >> Further down you replace the only call to
> > >> queue_invalidate_context() - why keep both functions instead of just
> > >> making
> > > the
> > >> existing one do the sync? (That would the likely also apply to
> > >> qinval_device_iotlb() and others below.)
> > >>
> > >
> > > It is optional.
> > >  I think:
> > > 1. in the long term, we may need no _sync version.
> > > 2. At least, the current wrap looks good to me. e.g.
> > > queue_invalidate_context() is for context-cache Invalidate Descriptor,
> > > and the
> > > invalidate_sync() is for Invalidation Wait Descriptor. It is much clearer.
> >
> > I don't really agree, but will leave it to the VT-d maintainers to judge.
> >
> 
> +to Kevin and Feng, I am open for it.

Let's just change existing one to _sync.

> 
> 
> > >> > +        if ( ret )
> > >> > +            return ret;
> > >> > +
> > >> >          if ( flush_dev_iotlb )
> > >> >              ret = dev_invalidate_iotlb(iommu, did, addr, size_order,
> > type);
> > >> > -        rc = invalidate_sync(iommu);
> > >> > -        if ( !ret )
> > >> > -            ret = rc;
> > >> >      }
> > >>
> > >> I think leaving the existing logic as is would be better - best
> > >> effort
> > > invalidation
> > >> even when an error has occurred.
> > >>
> > >
> > > I have an open:
> > > As vt-d spec(:Queued Invalidation Ordering Considerations) said,
> > >      1. If the Fence(FN) flag is 1 in a inv_wait_dsc, hardware must
> > > execute descriptors following the inv_wait_dsc only after wait command is
> > completed.
> > >      2. when a Device-TLB invalidation timeout is detected, hardware
> > > must not complete any pending inv_wait_dsc commands.
> > > In current code, the Fence(FN) is always 1.
> > > if a Device-TLB invalidation timeout is detected, this additional
> > > inv_wait_dsc is not completed.
> > > __iiuc__,
> > > the new coming descriptors, in that queue, _might_ be not executed any
> > > more, waiting for this additional inv_wait_dsc which is not completed.
> > > is it true?
> >
> > That's not a question to me, is it?
> 
> To community, but vt-d maintainers are someone who can explain to me.
> 

'not completed' here means 'abort', so your timeout check will be
hit since the status is never 'done' then.

But I'm not sure how your question is related to Jan's comment, which
looks reasonable to me. :-)

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

  reply	other threads:[~2016-04-11  7:25 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
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 [this message]
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=AADFC41AFE54684AB9EE6CBC0274A5D15F817D3F@SHSMSX101.ccr.corp.intel.com \
    --to=kevin.tian@intel.com \
    --cc=JBeulich@suse.com \
    --cc=dario.faggioli@citrix.com \
    --cc=feng.wu@intel.com \
    --cc=quan.xu@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).