On Thu, Oct 25, 2007 at 09:31:02AM +0200, Takashi Iwai wrote:
> At Wed, 24 Oct 2007 16:30:37 -0700,
> Mark Gross wrote:
> >
> > On Tue, Oct 23, 2007 at 10:57:51AM +0200, Takashi Iwai wrote:
> > > Fix possible array overflow:
> > >
> > > drivers/pci/intel-iommu.c: In function
On Thu, Oct 25, 2007 at 09:31:02AM +0200, Takashi Iwai wrote:
At Wed, 24 Oct 2007 16:30:37 -0700,
Mark Gross wrote:
On Tue, Oct 23, 2007 at 10:57:51AM +0200, Takashi Iwai wrote:
Fix possible array overflow:
drivers/pci/intel-iommu.c: In function ‘dmar_get_fault_reason’:
On Tue, Oct 23, 2007 at 01:01:56AM -0700, David Miller wrote:
>
> I would like to potentially move the sparc64 IOMMU code over to using
> the nice new drivers/pci/iova.[ch] code for free area management..
Welcome!!
>
> In order to do that we have to detach the IOMMU page size assumptions
>
On Tue, Oct 23, 2007 at 01:01:56AM -0700, David Miller wrote:
I would like to potentially move the sparc64 IOMMU code over to using
the nice new drivers/pci/iova.[ch] code for free area management..
Welcome!!
In order to do that we have to detach the IOMMU page size assumptions
which only
On Tue, Oct 23, 2007 at 01:59:26PM +0900, FUJITA Tomonori wrote:
> drivers/pci/intel-iommu.c: In function 'intel_unmap_sg':
> drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist' has no member
> named 'page'
> drivers/pci/intel-iommu.c: In function 'intel_nontranslate_map_sg':
>
On Tue, Oct 23, 2007 at 01:59:26PM +0900, FUJITA Tomonori wrote:
drivers/pci/intel-iommu.c: In function 'intel_unmap_sg':
drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist' has no member
named 'page'
drivers/pci/intel-iommu.c: In function 'intel_nontranslate_map_sg':
On Thu, Oct 04, 2007 at 01:39:39PM +1000, Benjamin Herrenschmidt wrote:
>
> > > Why don't you use the new struct dev_archdata mechanism ? That's what I
> > > use on powerpc to provide optional iommu linkage to any device in the
> > > system.
> > Good one. I will certainly try out your idea and
On Thu, Oct 04, 2007 at 01:39:39PM +1000, Benjamin Herrenschmidt wrote:
Why don't you use the new struct dev_archdata mechanism ? That's what I
use on powerpc to provide optional iommu linkage to any device in the
system.
Good one. I will certainly try out your idea and will update
On Thu, Oct 04, 2007 at 11:19:33AM +1000, Benjamin Herrenschmidt wrote:
> > Index: 2.6-mm/include/linux/pci.h
> > ===
> > --- 2.6-mm.orig/include/linux/pci.h 2007-10-03 13:48:20.0 -0700
> > +++ 2.6-mm/include/linux/pci.h
On Wed, Oct 03, 2007 at 02:12:03PM -0700, Andrew Morton wrote:
> On Mon, 1 Oct 2007 09:12:56 -0700
> "Keshavamurthy, Anil S" <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Sep 29, 2007 at 05:16:38AM -0700, FUJITA Tomonori wrote:
> > >
> > >
Subject: [patch][Intel-IOMMU] Fix for IOMMU early crash
pci_dev's->sysdata is highly overloaded and currently
IOMMU is broken due to IOMMU code depending on this field.
This patch introduces new field in pci_dev's struct to
hold IOMMU specific per device IOMMU private data.
Signed-off-by: Anil
Subject: [patch][Intel-IOMMU] Fix for IOMMU early crash
pci_dev's-sysdata is highly overloaded and currently
IOMMU is broken due to IOMMU code depending on this field.
This patch introduces new field in pci_dev's struct to
hold IOMMU specific per device IOMMU private data.
Signed-off-by: Anil S
On Wed, Oct 03, 2007 at 02:12:03PM -0700, Andrew Morton wrote:
On Mon, 1 Oct 2007 09:12:56 -0700
Keshavamurthy, Anil S [EMAIL PROTECTED] wrote:
On Sat, Sep 29, 2007 at 05:16:38AM -0700, FUJITA Tomonori wrote:
x86_64 defines ARCH_HAS_SG_CHAIN. So if IOMMU implementations don't
On Thu, Oct 04, 2007 at 11:19:33AM +1000, Benjamin Herrenschmidt wrote:
Index: 2.6-mm/include/linux/pci.h
===
--- 2.6-mm.orig/include/linux/pci.h 2007-10-03 13:48:20.0 -0700
+++ 2.6-mm/include/linux/pci.h
On Sat, Sep 29, 2007 at 05:16:38AM -0700, FUJITA Tomonori wrote:
>
>x86_64 defines ARCH_HAS_SG_CHAIN. So if IOMMU implementations don't
>support sg chaining, we will get data corruption.
>Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Acked-by: Anil S Keshavamurthy <[EMAIL
On Sat, Sep 29, 2007 at 05:16:38AM -0700, FUJITA Tomonori wrote:
x86_64 defines ARCH_HAS_SG_CHAIN. So if IOMMU implementations don't
support sg chaining, we will get data corruption.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Acked-by: Anil S Keshavamurthy [EMAIL PROTECTED]
On Wed, Sep 26, 2007 at 10:09:33AM +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Sep 25, 2007 at 06:12:38PM -0400, Avishay Traeger wrote:
> > Hello,
> > I am trying to use kprobes to measure the latency of a function by
> > instrumenting its call site. Basically, I find the call instruction,
On Wed, Sep 26, 2007 at 10:09:33AM +0530, Ananth N Mavinakayanahalli wrote:
On Tue, Sep 25, 2007 at 06:12:38PM -0400, Avishay Traeger wrote:
Hello,
I am trying to use kprobes to measure the latency of a function by
instrumenting its call site. Basically, I find the call instruction,
and
On Sat, Sep 15, 2007 at 02:30:40AM +1000, Paul Mackerras wrote:
> Keshavamurthy, Anil S writes:
>
> > Can I expect the ppc64 code changes from you?
> > Once I get your, I will merge with mine and post it again.
>
> Sure, but it will be next week, since I am travelling
On Sat, Sep 15, 2007 at 02:30:40AM +1000, Paul Mackerras wrote:
Keshavamurthy, Anil S writes:
Can I expect the ppc64 code changes from you?
Once I get your, I will merge with mine and post it again.
Sure, but it will be next week, since I am travelling this week.
Any progress?
-Anil
On Fri, Sep 14, 2007 at 02:31:59PM -0700, Siddha, Suresh B wrote:
> On Fri, Sep 14, 2007 at 02:00:02PM -0700, Jeremy Fitzhardinge wrote:
> > Keshavamurthy, Anil S wrote:
> > > Subject: [patch] Fix BIOS-e820 end address
> > >
> > > --snip of boot message--
On Fri, Sep 14, 2007 at 02:31:59PM -0700, Siddha, Suresh B wrote:
On Fri, Sep 14, 2007 at 02:00:02PM -0700, Jeremy Fitzhardinge wrote:
Keshavamurthy, Anil S wrote:
Subject: [patch] Fix BIOS-e820 end address
--snip of boot message--
BIOS-provided physical RAM map:
BIOS-e820
On Wed, Sep 12, 2007 at 05:48:52AM +1000, Paul Mackerras wrote:
> Keshavamurthy, Anil S writes:
>
> > Subject: Fix IOMMU early crash
> >
> > This patch avoids copying pci_bus's->sysdata to
> > pci_dev's->sysdata as one can easily obtain
> &
On Wed, Sep 12, 2007 at 05:48:52AM +1000, Paul Mackerras wrote:
> Keshavamurthy, Anil S writes:
>
> > Subject: Fix IOMMU early crash
> >
> > This patch avoids copying pci_bus's->sysdata to
> > pci_dev's->sysdata as one can easily obtain
> &
Subject: Fix IOMMU early crash
This patch avoids copying pci_bus's->sysdata to
pci_dev's->sysdata as one can easily obtain
the same through pci_dev->bus->sysdata.
Now with some recent pci_sysdata patches,
the bus's->sysdata gets populated way early
and a value of non-NULL gets copied from
Subject: Fix IOMMU early crash
This patch avoids copying pci_bus's-sysdata to
pci_dev's-sysdata as one can easily obtain
the same through pci_dev-bus-sysdata.
Now with some recent pci_sysdata patches,
the bus's-sysdata gets populated way early
and a value of non-NULL gets copied from
On Wed, Sep 12, 2007 at 05:48:52AM +1000, Paul Mackerras wrote:
Keshavamurthy, Anil S writes:
Subject: Fix IOMMU early crash
This patch avoids copying pci_bus's-sysdata to
pci_dev's-sysdata as one can easily obtain
the same through pci_dev-bus-sysdata.
At the moment
On Wed, Sep 12, 2007 at 05:48:52AM +1000, Paul Mackerras wrote:
Keshavamurthy, Anil S writes:
Subject: Fix IOMMU early crash
This patch avoids copying pci_bus's-sysdata to
pci_dev's-sysdata as one can easily obtain
the same through pci_dev-bus-sysdata.
At the moment
On Mon, Sep 10, 2007 at 11:25:43PM +0300, Muli Ben-Yehuda wrote:
> On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
>
> > Yes, I agree that pci_dev->sysdata can;t be removed. Even we (IOMMU)
> > were dependent on this field but somehow this field is
On Mon, Sep 10, 2007 at 03:37:48AM +1000, Paul Mackerras wrote:
> Keshavamurthy, Anil S writes:
>
> > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
> >
> > Populating pci_bus->sysdata way early in the pci discovery phase
> > sets NON-NULL value
On Sun, Sep 09, 2007 at 08:51:40PM +0300, Muli Ben-Yehuda wrote:
> On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote:
> > On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
> > > On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamu
On Sun, Sep 09, 2007 at 08:51:40PM +0300, Muli Ben-Yehuda wrote:
On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote:
On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
Subject
On Mon, Sep 10, 2007 at 03:37:48AM +1000, Paul Mackerras wrote:
Keshavamurthy, Anil S writes:
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
Populating pci_bus-sysdata way early in the pci discovery phase
sets NON-NULL value to pci_dev-sysdata which breaks the assumption
On Mon, Sep 10, 2007 at 11:25:43PM +0300, Muli Ben-Yehuda wrote:
On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
Yes, I agree that pci_dev-sysdata can;t be removed. Even we (IOMMU)
were dependent on this field but somehow this field is being
overwritten to point
On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
> On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
>
> > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
>
> This patch feels like a huge hack. See below.
You seem to be jumping to
On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
This patch feels like a huge hack. See below.
You seem to be jumping to conclusion without going
Subject: [patch] Fix BIOS-e820 end address
--snip of boot message--
BIOS-provided physical RAM map:
BIOS-e820: - 000a (usable)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 7fe8cc00 (usable)
end snip---
As you
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
Populating pci_bus->sysdata way early in the pci discovery phase
sets NON-NULL value to pci_dev->sysdata which breaks the assumption
in the Intel IOMMU driver and crashes the system.
In the drivers/pci/probe.c, pci_dev->sysdata gets a copy
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
Populating pci_bus-sysdata way early in the pci discovery phase
sets NON-NULL value to pci_dev-sysdata which breaks the assumption
in the Intel IOMMU driver and crashes the system.
In the drivers/pci/probe.c, pci_dev-sysdata gets a copy of
Subject: [patch] Fix BIOS-e820 end address
--snip of boot message--
BIOS-provided physical RAM map:
BIOS-e820: - 000a (usable)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 7fe8cc00 (usable)
end snip---
As you
On Wed, Aug 01, 2007 at 04:45:54PM -0700, Andrew Morton wrote:
> On Wed, 1 Aug 2007 13:06:23 -0700
> "Keshavamurthy, Anil S" <[EMAIL PROTECTED]> wrote:
>
> > +/* Computes the padding size required, to make the
> > + * the start address naturally aligned
On Wed, Aug 01, 2007 at 04:45:54PM -0700, Andrew Morton wrote:
On Wed, 1 Aug 2007 13:06:23 -0700
Keshavamurthy, Anil S [EMAIL PROTECTED] wrote:
+/* Computes the padding size required, to make the
+ * the start address naturally aligned on its size
+ */
+static int
+iova_get_pad_size
This patch adds PageSelectiveInvalidation support
replacing existing DomainSelectiveInvalidation for
intel_{map/unmap}_sg() calls and also enables
to mapping one big contiguous DMA virtual address
which is mapped to discontiguous physical address
for SG map/unmap calls.
"Doamin selective
This patch adds PageSelectiveInvalidation support
replacing existing DomainSelectiveInvalidation for
intel_{map/unmap}_sg() calls and also enables
to mapping one big contiguous DMA virtual address
which is mapped to discontiguous physical address
for SG map/unmap calls.
Doamin selective
To: Pavel Emelianov
Cc: Raj, Ashok; Li, Shaohua; Keshavamurthy, Anil S; Linux Kernel Mailing
List; Andrew Morton
Subject: Re: OOPS at dmar_table_init (2.6.22-rc6-mm1 kernel)
On Tue, 10 Jul 2007 17:57:25 +0400 Pavel Emelianov wrote:
> Hi.
>
> While working with Andrew's kernel I faced an OOPS
To: Pavel Emelianov
Cc: Raj, Ashok; Li, Shaohua; Keshavamurthy, Anil S; Linux Kernel Mailing
List; Andrew Morton
Subject: Re: OOPS at dmar_table_init (2.6.22-rc6-mm1 kernel)
On Tue, 10 Jul 2007 17:57:25 +0400 Pavel Emelianov wrote:
Hi.
While working with Andrew's kernel I faced an OOPS on x86_64
On Sun, Jul 01, 2007 at 10:22:43PM +0200, Adrian Bunk wrote:
> On Thu, Jun 28, 2007 at 03:43:21AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.22-rc4-mm2:
> >...
> > +intel-iommu-intel-iommu-driver.patch
> >...
> > Intel IOMMU support
> >...
>
>
> Contrary to popular belief, two
On Sun, Jul 01, 2007 at 10:22:43PM +0200, Adrian Bunk wrote:
On Thu, Jun 28, 2007 at 03:43:21AM -0700, Andrew Morton wrote:
...
Changes since 2.6.22-rc4-mm2:
...
+intel-iommu-intel-iommu-driver.patch
...
Intel IOMMU support
...
Contrary to popular belief, two identical Makefile
On Fri, Jun 29, 2007 at 12:23:43PM -0400, Muli Ben-Yehuda wrote:
> On Fri, Jun 29, 2007 at 08:28:58AM -0700, Keshavamurthy, Anil S wrote:
>
> > +++ linux-2.6.22-rc4-mm2/drivers/pci/dmar.c 2007-06-29 07:46:25.0
> > -0700
> > @@ -260,6 +260,8 @@
> > i
On Thu, Jun 28, 2007 at 06:14:27PM -0700, Li, Shaohua wrote:
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-
> >rc6/2.6.22-rc6-mm1/
> >>
> >>> +intel-iommu-dmar-detection-and-parsing-logic.patch
[..]
> >
> >I took a picture of it, looks like the backtrace is:
> >
>
On Thu, Jun 28, 2007 at 06:14:27PM -0700, Li, Shaohua wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-
rc6/2.6.22-rc6-mm1/
+intel-iommu-dmar-detection-and-parsing-logic.patch
[..]
I took a picture of it, looks like the backtrace is:
NULL pointer
On Fri, Jun 29, 2007 at 12:23:43PM -0400, Muli Ben-Yehuda wrote:
On Fri, Jun 29, 2007 at 08:28:58AM -0700, Keshavamurthy, Anil S wrote:
+++ linux-2.6.22-rc4-mm2/drivers/pci/dmar.c 2007-06-29 07:46:25.0
-0700
@@ -260,6 +260,8 @@
int ret = 0;
dmar = (struct
On Tue, Jun 26, 2007 at 12:37:55PM +0200, Andi Kleen wrote:
>
> > > Index: linux-2.6.22-rc4-mm2/arch/x86_64/Kconfig
> > > ===
> > > --- linux-2.6.22-rc4-mm2.orig/arch/x86_64/Kconfig 2007-06-18
> > > 15:45:08.0 -0700
> > >
On Mon, Jun 25, 2007 at 11:25:11PM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2007 14:37:06 -0700 "Keshavamurthy, Anil S" <[EMAIL
> PROTECTED]> wrote:
>
>
> None of these actually _need_ to be macros and it would be better to
> implement them in C. That wa
On Mon, Jun 25, 2007 at 11:32:49PM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2007 16:32:23 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
>
> > On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
> >
> > > +static inline void *alloc_pgtable_page
On Mon, Jun 25, 2007 at 11:42:22PM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2007 14:37:11 -0700 "Keshavamurthy, Anil S" <[EMAIL
> PROTECTED]> wrote:
>
> Bit weird that this was implemented in the header like that.
Sorry, it is my mistake as I understood thus fr
On Mon, Jun 25, 2007 at 11:07:47PM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2007 14:37:05 -0700 "Keshavamurthy, Anil S" <[EMAIL
> PROTECTED]> wrote:
>
> All the inlines in this code are pretty pointless: all those functions have
> a single callsite so the compi
On Tue, Jun 26, 2007 at 11:11:25AM -0400, Muli Ben-Yehuda wrote:
> On Tue, Jun 26, 2007 at 08:03:59AM -0700, Arjan van de Ven wrote:
> > Muli Ben-Yehuda wrote:
> > >How much? we have numbers (to be presented at OLS later this week)
> > >that show that on bare-metal an IOMMU can cost as much as
On Mon, Jun 25, 2007 at 10:49:37PM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2007 14:37:03 -0700 "Keshavamurthy, Anil S" <[EMAIL
> PROTECTED]> wrote:
>
> > +struct pci_dev *
> > +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
>
> You didn't nee
On Mon, Jun 25, 2007 at 10:49:37PM -0700, Andrew Morton wrote:
On Tue, 19 Jun 2007 14:37:03 -0700 Keshavamurthy, Anil S [EMAIL
PROTECTED] wrote:
+struct pci_dev *
+pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
You didn't need a newline there, but that's what the rest of that file
On Tue, Jun 26, 2007 at 11:11:25AM -0400, Muli Ben-Yehuda wrote:
On Tue, Jun 26, 2007 at 08:03:59AM -0700, Arjan van de Ven wrote:
Muli Ben-Yehuda wrote:
How much? we have numbers (to be presented at OLS later this week)
that show that on bare-metal an IOMMU can cost as much as 15%-30% more
On Mon, Jun 25, 2007 at 11:07:47PM -0700, Andrew Morton wrote:
On Tue, 19 Jun 2007 14:37:05 -0700 Keshavamurthy, Anil S [EMAIL
PROTECTED] wrote:
All the inlines in this code are pretty pointless: all those functions have
a single callsite so the compiler inlines them anyway. If we later
On Mon, Jun 25, 2007 at 11:42:22PM -0700, Andrew Morton wrote:
On Tue, 19 Jun 2007 14:37:11 -0700 Keshavamurthy, Anil S [EMAIL
PROTECTED] wrote:
Bit weird that this was implemented in the header like that.
Sorry, it is my mistake as I understood thus from your previous
code review comment
On Mon, Jun 25, 2007 at 11:32:49PM -0700, Andrew Morton wrote:
On Tue, 19 Jun 2007 16:32:23 -0700 (PDT) Christoph Lameter [EMAIL
PROTECTED] wrote:
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
+static inline void *alloc_pgtable_page(void)
+{
+ return (void *)get_zeroed_page
On Mon, Jun 25, 2007 at 11:25:11PM -0700, Andrew Morton wrote:
On Tue, 19 Jun 2007 14:37:06 -0700 Keshavamurthy, Anil S [EMAIL
PROTECTED] wrote:
None of these actually _need_ to be macros and it would be better to
implement them in C. That way things are more self-documenting, more
On Tue, Jun 26, 2007 at 12:37:55PM +0200, Andi Kleen wrote:
Index: linux-2.6.22-rc4-mm2/arch/x86_64/Kconfig
===
--- linux-2.6.22-rc4-mm2.orig/arch/x86_64/Kconfig 2007-06-18
15:45:08.0 -0700
+++
On Thu, Jun 21, 2007 at 09:13:11AM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
> > On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
> > > On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> >
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
> > Peter Zijlstra wrote:
> Also, the other iommu code you pointed me to, was happy to fail, it did
> not attempt to use the emergency reserves.
Is the same behavior
On Wed, Jun 20, 2007 at 11:11:05PM -0700, Arjan van de Ven wrote:
> Peter Zijlstra wrote:
> >What I'm saying is that if you do use the reserves, you should ensure
> >the use is bounded. I'm not seeing anything like that.
>
> each mapping takes at most 3 pages
With 3 pages(3 level page table),
On Wed, Jun 20, 2007 at 11:11:05PM -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
What I'm saying is that if you do use the reserves, you should ensure
the use is bounded. I'm not seeing anything like that.
each mapping takes at most 3 pages
With 3 pages(3 level page table), IOMMU can
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
Also, the other iommu code you pointed me to, was happy to fail, it did
not attempt to use the emergency reserves.
Is the same behavior acceptable
On Thu, Jun 21, 2007 at 09:13:11AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:37 -0700, Keshavamurthy, Anil S wrote:
On Thu, Jun 21, 2007 at 08:29:34AM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 23:11 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
Also
On Wed, Jun 20, 2007 at 10:08:51PM +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
> > Peter Zijlstra wrote:
> > > So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
> > > ensure they themselves will not block on a memory allocation. And
On Wed, Jun 20, 2007 at 10:08:51PM +0200, Peter Zijlstra wrote:
On Wed, 2007-06-20 at 12:14 -0700, Arjan van de Ven wrote:
Peter Zijlstra wrote:
So a reclaim context (kswapd and direct reclaim) set PF_MEMALLOC to
ensure they themselves will not block on a memory allocation. And it is
On Tue, Jun 19, 2007 at 04:32:23PM -0700, Christoph Lameter wrote:
> On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
>
> > +static inline void *alloc_pgtable_page(void)
> > +{
> > + return (void *)get_zeroed_page(GFP_ATOMIC);
> > +}
>
> Need to pas
This config option (DMAR_FLPY_WA) sets up 1:1 mapping for the
floppy device so that the floppy device which does not use
DMA api's will continue to work.
Once the floppy driver starts using DMA api's this config option
can be turn off or this patch can be yanked out of kernel at that
MSI interrupt handler registrations and fault handling support
for Intel-IOMMU hadrware.
This patch enables the MSI interrupts for the DMA remapping units
and in the interrupt handler read the fault cause and outputs the
same on to the console.
Signed-off-by: Anil S Keshavamurthy <[EMAIL
This code implements a generic IOVA allocation and
management. As per Dave's suggestion we are now allocating
IO virtual address from Higher DMA limit address rather
than lower end address and this eliminated the need to preserve
the IO virtual address for multiple devices sharing the
When we fix all the opensource gfx drivers to use the DMA api's,
at that time we can yank this config options out.
Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
---
Documentation/Intel-IOMMU.txt |5 +
arch/x86_64/Kconfig | 11 +++
arch/x86_64/kernel/e820.c
Introduce intel_iommu=forcedac commandline option.
This option is helpful to verify the pci device capability
of handling physical dma'able address greater than 4G.
Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |7 +++
Introduce the size param for clflush_cache_range().
Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>
---
arch/x86_64/mm/pageattr.c |6 +++---
include/asm-x86_64/cacheflush.h |1 +
2 files changed, 4 insertions(+), 3 deletions(-)
Index:
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables and for other data structures. As we all know that these DMA
map calls are mostly called in the interrupt context or with the spinlock
held by the upper level drivers(network/storage drivers), so in order to
This patch adds support for early detection and parsing of DMAR's
(DMA Remapping ) reported to OS via ACPI tables.
DMA remapping(DMAR) devices support enables independent address
translations for Direct Memory Access(DMA) from Devices.
These DMA remapping devices are reported via ACPI tables
and
When devices are under a p2p bridge, upstream
transactions get replaced by the device id of the bridge as it owns the
PCIE transaction. Hence its necessary to setup translations on behalf of the
bridge as well. Due to this limitation all devices under a p2p share the same
domain in a DMAR.
We
Hi All,
This patch supports the upcomming Intel IOMMU hardware
a.k.a. Intel(R) Virtualization Technology for Directed I/O
Architecture and the hardware spec for the same can be found here
http://www.intel.com/technology/virtualization/index.htm
This version of the patches
Hi All,
This patch supports the upcomming Intel IOMMU hardware
a.k.a. Intel(R) Virtualization Technology for Directed I/O
Architecture and the hardware spec for the same can be found here
http://www.intel.com/technology/virtualization/index.htm
This version of the patches
This patch adds support for early detection and parsing of DMAR's
(DMA Remapping ) reported to OS via ACPI tables.
DMA remapping(DMAR) devices support enables independent address
translations for Direct Memory Access(DMA) from Devices.
These DMA remapping devices are reported via ACPI tables
and
When devices are under a p2p bridge, upstream
transactions get replaced by the device id of the bridge as it owns the
PCIE transaction. Hence its necessary to setup translations on behalf of the
bridge as well. Due to this limitation all devices under a p2p share the same
domain in a DMAR.
We
Intel IOMMU driver needs memory during DMA map calls to setup its internal
page tables and for other data structures. As we all know that these DMA
map calls are mostly called in the interrupt context or with the spinlock
held by the upper level drivers(network/storage drivers), so in order to
Introduce intel_iommu=forcedac commandline option.
This option is helpful to verify the pci device capability
of handling physical dma'able address greater than 4G.
Signed-off-by: Anil S Keshavamurthy [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |7 +++
Introduce the size param for clflush_cache_range().
Signed-off-by: Anil S Keshavamurthy [EMAIL PROTECTED]
---
arch/x86_64/mm/pageattr.c |6 +++---
include/asm-x86_64/cacheflush.h |1 +
2 files changed, 4 insertions(+), 3 deletions(-)
Index:
When we fix all the opensource gfx drivers to use the DMA api's,
at that time we can yank this config options out.
Signed-off-by: Anil S Keshavamurthy [EMAIL PROTECTED]
---
Documentation/Intel-IOMMU.txt |5 +
arch/x86_64/Kconfig | 11 +++
arch/x86_64/kernel/e820.c
This code implements a generic IOVA allocation and
management. As per Dave's suggestion we are now allocating
IO virtual address from Higher DMA limit address rather
than lower end address and this eliminated the need to preserve
the IO virtual address for multiple devices sharing the
This config option (DMAR_FLPY_WA) sets up 1:1 mapping for the
floppy device so that the floppy device which does not use
DMA api's will continue to work.
Once the floppy driver starts using DMA api's this config option
can be turn off or this patch can be yanked out of kernel at that
MSI interrupt handler registrations and fault handling support
for Intel-IOMMU hadrware.
This patch enables the MSI interrupts for the DMA remapping units
and in the interrupt handler read the fault cause and outputs the
same on to the console.
Signed-off-by: Anil S Keshavamurthy [EMAIL
On Tue, Jun 19, 2007 at 04:32:23PM -0700, Christoph Lameter wrote:
On Tue, 19 Jun 2007, Keshavamurthy, Anil S wrote:
+static inline void *alloc_pgtable_page(void)
+{
+ return (void *)get_zeroed_page(GFP_ATOMIC);
+}
Need to pass gfp_t parameter. Repeates a couple of times
On Thu, Jun 07, 2007 at 04:57:39PM -0700, Andrew Morton wrote:
> On Wed, 06 Jun 2007 11:57:04 -0700
> [EMAIL PROTECTED] wrote:
Andrew,
Most of your comments make sense, I will fix all of them and resend
soon.
Thanks for your time taking a look at my patch.
-Anil
-
To unsubscribe from
On Thu, Jun 07, 2007 at 04:57:39PM -0700, Andrew Morton wrote:
On Wed, 06 Jun 2007 11:57:04 -0700
[EMAIL PROTECTED] wrote:
Andrew,
Most of your comments make sense, I will fix all of them and resend
soon.
Thanks for your time taking a look at my patch.
-Anil
-
To unsubscribe from this
On Mon, Jun 11, 2007 at 02:14:49PM -0700, Andrew Morton wrote:
> On Mon, 11 Jun 2007 13:44:42 -0700
> "Keshavamurthy, Anil S" <[EMAIL PROTECTED]> wrote:
>
> > In the first implementation of ours, we had used mempools api's to
> > allocate memory and we we
On Tue, Jun 12, 2007 at 12:25:57AM +0200, Andi Kleen wrote:
>
> > Please advice.
>
> I think the short term only safe option would be to fully preallocate an
> aperture.
> If it is too small you can try GFP_ATOMIC but it would be just
> a unreliable fallback. For safety you could perhaps have
1 - 100 of 164 matches
Mail list logo
