From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jan Beulich <JBeulich@suse.com>,
"Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Malcolm Crossley <malcolm.crossley@citrix.com>,
"Dugger, Donald D" <donald.d.dugger@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: VT-d spin loops
Date: Wed, 23 Jul 2014 16:17:58 +0000 [thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D125FEC416@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <53CF88A40200007800024F91@mail.emea.novell.com>
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, July 23, 2014 1:04 AM
>
> >>> On 15.07.14 at 10:00, <yang.z.zhang@intel.com> wrote:
> > Andrew Cooper wrote on 2014-07-10:
> >> On 10/07/14 00:22, Tian, Kevin wrote:
> >>> ATS should be fine. Device TLB can ONLY be validated through qinval
> >>> interface, which is asynchronous so no need to consider 1 minute
> >>> timeout even in current spinning model.
> >>
> >> There are currently no asynchronous invalidations in Xen. ATS
> >> certainly is a problem.
> >
> > How Linux upstream handle ATS? Does it have any asynchronous
> invalidations
> > mechanism?
>
> Not according to my inspection of the code.
>
> >>> In general yes a non-spinning model is better, but it requires
> >>> non-trivial change to make all IOMMU operations asynchronous. If ATS
> >>> is not a concern, is it still worthy of change besides auditing existing
> > usages?
> >>
> >> Even if the invalidation is only at the IOMMU, waiting milliseconds
> >> for the completion is still time better spent elsewhere, such as running
> > VMs.
> >>
> >> Do you have any numbers for typical completion times for invalidate
> > requests?
> >>
> >
> > The invalidations are completed fairly quickly by hardware. So the cost for
> > spin can be ignored?
>
> No, we have to be prepared for a timeout to occur, without killing
> the entire host (killing the guest owning affected device would be
> acceptable as a consequence), even more so with the longer
> timeouts mandated by ATS.
>
right. for ATS we really need an asynchronous implementation, while
doing that also means whole spin loop concept is changed.
Thanks
Kevin
prev parent reply other threads:[~2014-07-23 16:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53A96B80020000780001CB8F@mail.emea.novell.com>
2014-06-26 10:30 ` VT-d spin loops Jan Beulich
2014-06-26 10:38 ` Andrew Cooper
2014-06-26 10:43 ` Andrew Cooper
2014-07-09 23:22 ` Tian, Kevin
2014-07-10 9:55 ` Andrew Cooper
2014-07-10 13:19 ` Dugger, Donald D
2014-07-10 15:53 ` Tian, Kevin
2014-07-15 8:00 ` Zhang, Yang Z
2014-07-23 8:04 ` Jan Beulich
2014-07-23 16:17 ` Tian, Kevin [this message]
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=AADFC41AFE54684AB9EE6CBC0274A5D125FEC416@SHSMSX101.ccr.corp.intel.com \
--to=kevin.tian@intel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=donald.d.dugger@intel.com \
--cc=malcolm.crossley@citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=yang.z.zhang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.