> > 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@lists.xensource.com
http://lists.xensource.com/xen-merge
> > 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@lists.xensource.com
http://lists.xensource.com/xen-merge