|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] xen-swiotlb and linux swiotlb
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 ?
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 ?
--
Sander
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] xen-swiotlb and linux swiotlb,
Sander Eikelenboom <=
|
|
|
|
|