| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
On Tue, Apr 10, 2007 at 09:41:55AM +0100, Kieran Mansley wrote:
> It's not quite on the data path - it's hitting this problem when
> allocating buffers for network access, which typically will come
> from a preallocated pool rather than being on demand, so perhaps
> it's not a big problem.
>
> I've had a quick look at what's going on. The call into swiotlb comes
> from dma_map_single() (which is I think the one defined in
> arch/i386/kernel/pci-dma-xen.c). This happens because the swiotlb
> global is set to 1 in swiotlb_init(). It looks like this is unavoidable
> as there's a comment there saying:
> /* Domain 0 always has a swiotlb. */
>
> I could undefine CONFIG_SWIOTLB or set swiotlb_force to -1 and so
> avoid the whole thing, but I'm not sure that would be a good thing -
> some other drivers might depend on it.
swiotlb is used to give you machine-contigous buffers if your buffers
aren't machine-contigous. Just because it's enabled doesn't mean it
will be used - there's a check whether it's needed in every map/alloc
call and if it isn't it's not used. If all your buffers are
machine-contigous you shouldn't ever need to use any space in the
swiotlb aperture. If they aren't, that's probably the real problem.
Cheers,
Muli
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home