Mailing List Archive

On Tue, Jan 24, 2006 at 01:53:35PM -0600, Langsdorf, Mark wrote:
> I'm trying enable the IOMMU in AMD Opteron systems
> in the linux-2.6-xen.hg codebase.
>
> If I turn on CONFIG_GART_IOMMU in the Kconfig,
> enable it in the .config file, and build the
> kernel, I get errors because
> include/asm-i386/mach-xen/asm/dma-mapping.h
> is included instead of
> include/asm-x86_64/mach-xen/asm/dma-mapping.h
>
> I can't figure out how or where the build system
> decides which dma-mapping file to include. Help
> would be appreciated.

The build always uses include/asm, which should be symlink'd to the
right architecture's asm-$(ARCH) directory. Are you sure you're
building for x86-64? is gart the only thing that's pulling in the
wrong dma-mapping.h?

Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

> > If I turn on CONFIG_GART_IOMMU in the Kconfig,
> > enable it in the .config file, and build the
> > kernel, I get errors because
> > include/asm-i386/mach-xen/asm/dma-mapping.h
> > is included instead of
> > include/asm-x86_64/mach-xen/asm/dma-mapping.h
> >
> > I can't figure out how or where the build system
> > decides which dma-mapping file to include. Help
> > would be appreciated.
>
> The build always uses include/asm, which should be symlink'd
> to the right architecture's asm-$(ARCH) directory. Are you
> sure you're building for x86-64? is gart the only thing
> that's pulling in the wrong dma-mapping.h?

include/asm is correctly linked to include/asm-x86_64

poking around a bit, I found that asm/dma-mapping is
being included from include/linux/dma-mapping.h
If I force the include there to be asm-x86_64/dma-mapping.h,
the code compiles. That's not an acceptable long-term
solution, obviously.

There are some files in arch/x86_64/kernel that are
being compiled from arch/i386/kernel (such as swiotlb.c),
but the mainline tree does that too without this problem.

-Mark Langsdorf
AMD, Inc.


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On Tue, Jan 24, 2006 at 02:28:06PM -0600, Langsdorf, Mark wrote:

> poking around a bit, I found that asm/dma-mapping is
> being included from include/linux/dma-mapping.h
> If I force the include there to be asm-x86_64/dma-mapping.h,
> the code compiles. That's not an acceptable long-term
> solution, obviously.

But that's using <asm/dma-mapping.h>, which theoretically should do
the right thing.

> There are some files in arch/x86_64/kernel that are
> being compiled from arch/i386/kernel (such as swiotlb.c),
> but the mainline tree does that too without this problem.

Curious... do you have a patch I can try?

Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On Tue, Jan 24, 2006 at 10:34:45PM +0200, Muli Ben-Yehuda wrote:
> But that's using <asm/dma-mapping.h>, which theoretically should do
> the right thing.

The merge tree override the include path, to include
include/asm/mach-xen/ before include/

so <asm/dma-mapping.h> will be found in
include/asm/mach-xen/asm/dma-mapping.h instead of
include/asm/dma-mapping.h

Cheers,
--
Vincent Hanquez

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

> On Tue, Jan 24, 2006 at 10:34:45PM +0200, Muli Ben-Yehuda wrote:
> > But that's using <asm/dma-mapping.h>, which theoretically should do
> > the right thing.
>
> The merge tree override the include path, to include
> include/asm/mach-xen/ before include/
>
> so <asm/dma-mapping.h> will be found in
> include/asm/mach-xen/asm/dma-mapping.h instead of
> include/asm/dma-mapping.h

Right, but that doesn't explain why even though my
ARCH=x86_64, I'm being redirected to asm-i386 instead
of asm-x86_64.

Of course, the fact that asm-x86_64/mach-xen/asm/dma-mapping.h
consists solely of "#include <asm-i386/dma-mapping.h>"
does explain it.

Is there a particular reason that Xen merge doesn't want
to use lib/swiotlb.c and instead prefers
arch/i386/kernel/swiotlb.c instead?

-Mark Langsdorf
AMD, Inc.



_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On Tue, Jan 24, 2006 at 03:54:15PM -0600, Langsdorf, Mark wrote:

> Of course, the fact that asm-x86_64/mach-xen/asm/dma-mapping.h
> consists solely of "#include <asm-i386/dma-mapping.h>"
> does explain it.

:-)

> Is there a particular reason that Xen merge doesn't want
> to use lib/swiotlb.c and instead prefers
> arch/i386/kernel/swiotlb.c instead?

Yeah - it's substantially different. I hope the differences can be
narrowed down and code duplication minimized, possibly with judicious
use of dma-ops, but that will wait until the merge happens.

Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

> > Is there a particular reason that Xen merge doesn't want
> > to use lib/swiotlb.c and instead prefers
> > arch/i386/kernel/swiotlb.c instead?
>
> Yeah - it's substantially different. I hope the differences
> can be narrowed down and code duplication minimized, possibly
> with judicious use of dma-ops, but that will wait until the
> merge happens.

The differences are substantial enough that pci-gart.c
needs several functions that are only in lib/swiotlb.c.
Is xen-merge going to move up to 2.6.16 soon or should
I just figure out the Makefile magic to get x86_64 to
compile with lib/swiotlb.c if CONFIG_IOMMU_GART is
defined and arch/i386/kernel/swiotlb.c if it isn't?

-Mark Langsdorf
AMD, Inc.


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On 24 Jan 2006, at 21:58, Muli Ben-Yehuda wrote:

>> Is there a particular reason that Xen merge doesn't want
>> to use lib/swiotlb.c and instead prefers
>> arch/i386/kernel/swiotlb.c instead?
>
> Yeah - it's substantially different. I hope the differences can be
> narrowed down and code duplication minimized, possibly with judicious
> use of dma-ops, but that will wait until the merge happens.

I wrote the xen-specific swiotlb (ripped off from arch/ia64), and
really the only xen-specific part of the swiotlb implementation should
be that we need to take special care during initialisation that the
aperture contains contiguous machine memory. Apart from that, I expect
we need care to distinnguish between phys and machine addresses, but I
would expect no other differences.

I suspect our best bet is to take lib/swiotlb.c and work out minimal
changes to get it working on xen, cribbing from xen-specific swiotlb
where there are particular problems, rather than try and do a full
merge of the two swiotlbs. This is because most differences are
probably insignificant/gratuitous.

If someone who is already very familiar with the dma-mapping interfaces
wanted to investigate this, that would be super. :-)

-- Keir


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On Wed, Jan 25, 2006 at 09:56:27AM +0000, Keir Fraser wrote:

> I suspect our best bet is to take lib/swiotlb.c and work out minimal
> changes to get it working on xen, cribbing from xen-specific swiotlb
> where there are particular problems, rather than try and do a full
> merge of the two swiotlbs. This is because most differences are
> probably insignificant/gratuitous.
>
> If someone who is already very familiar with the dma-mapping interfaces
> wanted to investigate this, that would be super. :-)

I plan on looking on it as time permits. I wouldn't mind if someone
else did it first, though :-)

Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge