| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xen-swiotlb and linux swiotlb
On Sun, Aug 15, 2010 at 07:02:25PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
>
> Don't know if this is logical, since it uses the same range.
>
> [ 0.000000] Placing 64MB software IO TLB between ffff880003d00000 -
> ffff880007d00000
> [ 0.000000] software IO TLB at phys 0x3d00000 - 0x7d00000
>
> [ 0.047391] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [ 0.047402] Placing 64MB software IO TLB between ffff880003d00000 -
> ffff880007d00000
> [ 0.047406] software IO TLB at phys 0x3d00000 - 0x7d00000
>
>
> And with 2.6.36pre:
>
> [ 0.000000] DMA: Placing 64MB software IO TLB between ffff88000eb5d000 -
> ffff880012b5d000
> [ 0.000000] DMA: software IO TLB at phys 0xeb5d000 - 0x12b5d000
> [ 0.000000] xen_swiotlb_fixup: buf=ffff88000eb5d000 size=67108864
> [ 0.000000] xen_swiotlb_fixup: buf=ffff880012bbd000 size=32768
>
> [ 3.297348] DMA-API: preallocated 32768 debug entries
> [ 3.300022] DMA-API: debugging enabled by kernel config
> [ 3.300022] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [ 3.300022] DMA: Placing 64MB software IO TLB between ffff88000eb5d000 -
> ffff880012b5d000
> [ 3.300022] DMA: software IO TLB at phys 0xeb5d000 - 0x12b5d000
>
>
> Seems xen-swiotlb splits the mem space, and the 32768 is probably for a
> translaction table ?
I am not sure if you are referring to:
> [ 3.297348] DMA-API: preallocated 32768 debug entries
or:
> [ 0.000000] xen_swiotlb_fixup: buf=ffff880012bbd000 size=32768
The first is the entries for the DMA debug API. Every time your device
does an PCI map/unmap, that gets recorded in the API. And if you call
the 'debug_dma_dump_mappings' (see attached module). you get a nice
kernel dump of all the DMA kernel mappings. And you can count them up
to and see how much space is used.
The second is for an overflow buffer. That overflow buffer was used when
the main buffer (the 64MB) got completly used and we would use this 32kB
space as last ditch. It is going away and..
> Since it gets overriden by the normal swiotlb later on, this mem could be
> used by devices as DMA mem, and since it is on the end, it could take a while
> .. and finally overwrite mem it shouldn't and freeze everyting ?
.. we don't end up using it in Xen-SWIOTLB. So no worry about overwrite.
thought we do lose 32768 bytes of memory b/c of this.
In 2.6.38-timeframe I plan along with Fujita to remove this overflow_buffer
machination and make sure that most drivers used the 'pci_dma_mapping'
call to check if the region they got is DMA mappable instead of blindly
assuming that the pci_map_single call worked.
dump_dma.c
Description: Text document
Makefile
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home