From: Alex Williamson <alex_williamson@hp.com>
To: linux-ia64@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] Disable sba_iommu bypass to be compatible with bio-level block merging
Date: Fri, 27 Jun 2003 10:02:38 -0600 [thread overview]
Message-ID: <3EFC6A9E.28E47F4@hp.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
This patch works around a problem that David Mosberger
discovered prior to his 2.5.72 ia64 patch release. The
zx1 iommu driver has an optimization to allow devices that
can DMA directly to a memory address to completely bypass
the iommu. For sg mappings, we skip the coalescing and
everything. Effectively, this looks like a mixed bus system
and I don't see how to handle that with the current bio code.
IMHO, this really doesn't seem like an extraordinary
situation and I'm sure there are other platforms that might
hit it as well.
For now it seems like the best way to make things happy is
to disable the bypass feature and force all DMA to be mapped
through the iommu. The attached patch is against David's
last 2.5.72 ia64 patch. Much thanks to Grant Grundler for
really diving into this and discovering what was happening.
Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
[-- Attachment #2: sba_iommu-bypass-disable.diff --]
[-- Type: text/plain, Size: 1122 bytes --]
--- linux-2.5.72-orig/include/asm-ia64/io.h 2003-06-20 14:40:35.000000000 -0600
+++ linux-2.5.72/include/asm-ia64/io.h 2003-06-27 09:12:44.000000000 -0600
@@ -424,6 +424,6 @@
* which is precisely what we want.
*/
extern unsigned long ia64_max_iommu_merge_mask;
-#define BIO_VMERGE_BOUNDARY (0UL)//(ia64_max_iommu_merge_mask + 1)
+#define BIO_VMERGE_BOUNDARY (ia64_max_iommu_merge_mask + 1)
#endif /* _ASM_IA64_IO_H */
--- linux-2.5.72-orig/arch/ia64/hp/common/sba_iommu.c 2003-06-20 14:40:31.000000000 -0600
+++ linux-2.5.72/arch/ia64/hp/common/sba_iommu.c 2003-06-27 09:09:50.000000000 -0600
@@ -47,8 +47,11 @@
/*
** This option allows cards capable of 64bit DMA to bypass the IOMMU. If
** not defined, all DMA will be 32bit and go through the TLB.
+** The bio merge code currently expects that if we tweak that vmerge
+** boundary that we will alway coalesce blocks on that boundary. Enabling
+** this optimization is therefore incompatible with tuning the boundary.
*/
-#define ALLOW_IOV_BYPASS
+#undef ALLOW_IOV_BYPASS
/*
** If a device prefetches beyond the end of a valid pdir entry, it will cause
reply other threads:[~2003-06-27 15:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3EFC6A9E.28E47F4@hp.com \
--to=alex_williamson@hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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).