RE: [Xen-merge] AMD64 dma-mapping/swiotlb.c/more questions

["Langsdorf, Mark" <mark.langsdorf@xxxxxxx>]

> > 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.

IOMMU-GART support requires several function calls from lib/swiotlb.c
that aren't in arch/i386/kernel/swiotlb.c.  Which way should I try
to merge?
 
> 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 hope that's not directed at me. =)

I've got a hacky version of IOMMU-GART working in xen-merge, but
I'm seeing many instances of the following error:

clear_kernel_mapping: mapping has been split. will leak memory
arch/x86_64/mm/init-xen.c:728: bad pmd ffff8800016a9xxx (000...)

I'm not sure if this is a bogus error or not.  Comments around the
error indicate this "could be handled, but it should not happen
currently".  Anyone know what it means?

-Mark Langsdorf
AMD, Inc.


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