From: Jon Mason <jdmason@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Muli Ben-Yehuda <mulix@mulix.org>, Jon Mason <jdmason@us.ibm.com>,
Muli Ben-Yehuda <muli@il.ibm.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
discuss@x86-64.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 3/3] x86-64: Calgary IOMMU - hook it in
Date: Thu, 23 Mar 2006 11:30:48 -0600 [thread overview]
Message-ID: <20060323173047.GA30099@us.ibm.com> (raw)
In-Reply-To: <200603231736.44223.ak@suse.de>
On Thu, Mar 23, 2006 at 05:36:43PM +0100, Andi Kleen wrote:
> On Monday 20 March 2006 09:56, Muli Ben-Yehuda wrote:
> > This patch hooks Calgary into the build and the x86-64 IOMMU
> > initialization paths.
>
> Needs more description
>
> > diff -Naurp --exclude-from /home/muli/w/dontdiff iommu_detected/arch/x86_64/Kconfig linux/arch/x86_64/Kconfig
> > --- iommu_detected/arch/x86_64/Kconfig 2006-03-20 09:12:23.000000000 +0200
> > +++ linux/arch/x86_64/Kconfig 2006-03-20 09:30:10.000000000 +0200
> > @@ -372,6 +372,19 @@ config GART_IOMMU
> > and a software emulation used on other systems.
> > If unsure, say Y.
> >
> > +config CALGARY_IOMMU
> > + bool "IBM x366 server IOMMU"
> > + default y
> > + depends on PCI && MPSC && EXPERIMENTAL
>
> && MPSC is wrong. First most kernels are GENERIC and then even a K8 optimized
> kernel should support all hardware. Just drop it.
We have a recent modification to this chunk which does both generic and
em64t. Since IBM only ships this chip on em64t systems, have the option
on amd64 seems wrong.
> > + help
> > + Support for hardware IOMMUs in IBM's xSeries x366 and x460
> > + systems. Needed to run systems with more than 3GB of memory
> > + properly with 32-bit PCI devices that do not support DAC
> > + (Double Address Cycle). The IOMMU can be turned off at
> > + boot time with the iommu=off parameter. Normally the kernel
> > + will make the right choice by iteself.
> > + If unsure, say Y.
>
> If it does isolation then it has much more advantages than that
> by protecting against buggy devices and drivers and is also useful
> for debugging. You should mention that.
Will do.
> > +static int __init pci_iommu_init(void)
> > +{
> > + int rc = 0;
> > +
> > +#ifdef CONFIG_GART_IOMMU
> > + rc = gart_iommu_init();
> > + if (!rc) /* success? */
> > + return 0;
> > +#endif
> > +#ifdef CONFIG_CALGARY_IOMMU
> > + rc = calgary_iommu_init();
> > +#endif
>
> This is weird. Normally I would expect you to detect the calgary thing first
> and only then run the gart_iommu detection if not found. Why this order?
>
>
> Fixing that would also not require adding the additional hacks to gart iommu
> you added.
I'll look into this.
>
> > -/* Must execute after PCI subsystem */
> > -fs_initcall(pci_iommu_init);
>
> So where is it called now?
It is called in arch/x86_64/kernel/pci-dma.c
>
> > +#ifdef CONFIG_CALGARY_IOMMU
> > + if (!memcmp(from,"calgary=",8)) {
> > + calgary_parse_options(from+8);
> > + }
> > +#endif
>
> Why does this need to be an early option?
Because we need to know the size of the translation tables early, so
that we can alloc them from bootmem.
Thanks,
Jon
>
>
> -Andi
next prev parent reply other threads:[~2006-03-23 17:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 8:48 [PATCH 1/3] x86-64: Calgary IOMMU - introduce iommu_detected Muli Ben-Yehuda
2006-03-20 8:54 ` [PATCH 2/3] x86-64: Calgary IOMMU - Calgary specific bits Muli Ben-Yehuda
2006-03-20 8:56 ` [PATCH 3/3] x86-64: Calgary IOMMU - hook it in Muli Ben-Yehuda
2006-03-23 16:36 ` Andi Kleen
2006-03-23 17:30 ` Jon Mason [this message]
2006-03-23 17:48 ` Andi Kleen
2006-03-23 18:58 ` Jon Mason
2006-03-24 3:23 ` Muli Ben-Yehuda
2006-03-23 16:31 ` [PATCH 2/3] x86-64: Calgary IOMMU - Calgary specific bits Andi Kleen
2006-03-23 17:53 ` Muli Ben-Yehuda
2006-03-23 18:02 ` Andi Kleen
2006-03-23 19:03 ` Muli Ben-Yehuda
2006-03-23 21:45 ` Muli Ben-Yehuda
2006-03-23 21:52 ` Andi Kleen
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=20060323173047.GA30099@us.ibm.com \
--to=jdmason@us.ibm.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=mulix@mulix.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