linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: cody <mail.kai.huang@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	rajesh.sankaran@intel.com, iommu@lists.linux-foundation.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	chrisw@sous-sol.org, ddutile@redhat.com
Subject: Re: [PATCH] intel-iommu: Manage iommu_coherency globally
Date: Tue, 22 Nov 2011 23:30:10 -0800	[thread overview]
Message-ID: <4ECCA102.4040501@gmail.com> (raw)
In-Reply-To: <1321617817.15493.33.camel@shinybook.infradead.org>

On 11/18/2011 04:03 AM, David Woodhouse wrote:
>
> Hm, it seems I lied to you about this. The non-coherent mode isn't just
> a historical mistake; it's configurable by the BIOS, and we actually
> encourage people to use the non-coherent mode because it makes the
> hardware page-walk faster — so reduces the latency for IOTLB misses.
>
>    
I have a question, Intel VT-d manual says the coherency bit is "RO", how 
can it be configurable by the BIOS? Or there's another way to configure 
the IOMMU to be coherent or non-coherent? (I didn't find such info in 
the manual. I missed it?)

-cody
> In addition to that, the IOMMU associated with the integrated graphics
> is so "special" that it doesn't support coherent mode either. So it *is*
> quite feasible that we'll see a machine where some IOMMUs support
> coherent mode, and some don't.
>
> And thus we do need to address the concern that just assuming
> non-coherent mode will cause unnecessary performance issues, for the
> case where a domain *doesn't* happen to include any of the non-coherent
> IOMMUs.
>
> However... for VM domains I don't think we care. Setting up the page
> tables *isn't* a fast path there (at least not until/unless we support
> exposing an emulated IOMMU to the guest).
>
> The case we care about is *native* DMA, where this cache flush will be
> happening for example in the fast path of network TX/RX. But in *that*
> case, there is only *one* IOMMU to worry about so it's simple enough to
> do the right thing, surely?
>
>
>    

  parent reply	other threads:[~2011-11-22 15:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16  4:11 [PATCH] intel-iommu: Manage iommu_coherency globally Alex Williamson
2011-11-16 10:28 ` Chris Wright
2011-11-18 12:03 ` David Woodhouse
2011-11-18 16:03   ` Alex Williamson
2011-11-18 17:00     ` David Woodhouse
2011-11-18 17:15       ` Alex Williamson
2011-11-18 18:15         ` David Woodhouse
2011-11-19 19:17   ` Chris Wright
2011-11-19 20:11     ` David Woodhouse
2011-11-23  7:30   ` cody [this message]
2011-11-22 15:41     ` David Woodhouse

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=4ECCA102.4040501@gmail.com \
    --to=mail.kai.huang@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=ddutile@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rajesh.sankaran@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 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).