From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: "Yu, Fenghua" <fenghua.yu@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
David Woodhouse <dwmw2@infradead.org>,
Ingo Molnar <mingo@elte.hu>, Avi Kivity <avi@redhat.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>
Subject: Re: [PATCH 2/2]Add Variable Page Size and IA64 Support in Intel IOMMU: IA64 Specific Part
Date: Mon, 06 Oct 2008 14:55:35 +0000 [thread overview]
Message-ID: <200810060855.36880.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <A6AD88C3F2289247BE726C37303E1EB8844A6398@orsmsx505.amr.corp.intel.com>
On Friday 03 October 2008 06:53:04 pm Yu, Fenghua wrote:
> >> >This patch adds clflush_cache_range(), but it's not used anywhere.
> >> Clflush_cache_range() is used in __iommu_flush_cache() in include/linux/intel-iommu.h.
>
> >Oh, OK. I didn't look hard enough to find __iommu_flush_cache()
> > (currently in drivers/pci/intel-iommu.c).
>
> >Architecturally, I'm surprised that ia64 would need to actually do a
> >cache flush. I would think the VT-d hardware would do coherent accesses
> >which would make the cache flush unnecessary.
>
> VT-d hardware supports both non cache coherency and cache coherency by bit Coherency in Extended Capabilities Register.
>
> Could you please point me to the doc that explicitly says that architecturally ia64 doesn't need cache flush?
I don't know the details of VT-d, so I'm just asking the question. I
do know the HP IOMMU does not require flushing because it participates
in the coherency domain, so I was just surprised to see this in Intel
chipset support.
The following sections in volume 2 of the SDM mention DMA:
Part 1, Sec 4.4.3, Cacheability and Coherency Attribute:
The processor must ensure that transactions from other I/O agents
(such as DMA) are physically coherent with the instruction and data
cache.
Part 2, Sec 2.5.4, DMA:
Unlike Programmed I/O, which requires intervention from the CPU
to move data from the device to main memory, data movement in DMA
occurs without help from the CPU. A processor based on the Itanium
architecture expects the platform to maintain coherency for DMA
traffic. That is, the platform issues snoop cycles on the bus to
invalidate cacheable pages that a DMA access modifies. These snoop
cycles invalidate the appropriate lines in both instruction and
data caches and thus maintain coherency. This behavior allows an
operating system to page code pages without taking explicit actions
to ensure coherency.
Software must maintain coherency for DMA traffic through explicit
action if the platform does not maintain coherency for this traffic.
Software can provide coherency by using the flush cache instruction,
fc, to invalidate the instruction and data cache lines that a DMA
transfer modifies.
It sounds like the expectation is that DMA will be fully coherent
and no flushes would be required, but there is wiggle room in that
last paragraph for platforms that don't maintain coherency.
Bjorn
next prev parent reply other threads:[~2008-10-06 14:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 16:57 [PATCH 2/2]Add Variable Page Size and IA64 Support in Intel IOMMU: IA64 Specific Part Fenghua Yu
2008-10-02 15:51 ` Bjorn Helgaas
2008-10-02 17:46 ` [PATCH 2/2]Add Variable Page Size and IA64 Support in Intel Yu, Fenghua
2008-10-03 15:41 ` [PATCH 2/2]Add Variable Page Size and IA64 Support in Intel IOMMU: IA64 Specific Part Bjorn Helgaas
2008-10-04 0:53 ` [PATCH 2/2]Add Variable Page Size and IA64 Support in Intel Yu, Fenghua
2008-10-04 6:09 ` David Woodhouse
2008-10-04 14:17 ` Yu, Fenghua
2008-10-06 14:55 ` Bjorn Helgaas [this message]
2008-10-07 0:35 ` [PATCH 2/2]Add Variable Page Size and IA64 Support in Intel IOMMU: IA64 Specific Part Fenghua Yu
2008-11-24 19:53 ` [PATCH 1/2] Enable Pass Through Feature in Intel IOMMU Fenghua Yu
2008-10-07 0:02 ` [PATCH V2 2/2] Add Variable Page Size and IA64 Support in Intel IOMMU: IA64 Specific Part Fenghua Yu
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=200810060855.36880.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=akpm@linux-foundation.org \
--cc=avi@redhat.com \
--cc=dwmw2@infradead.org \
--cc=fenghua.yu@intel.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sfr@canb.auug.org.au \
--cc=tony.luck@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