[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disable swiotlb for Dom0

On 13/08/2021 10:38, Roman Skakun wrote:
Hi Julien,

Hi Roman,

So 0xb6000000 is most likely the GFN used to mapped the grant from the domU.

swiotlb-xen on Arm will convert it to the MFN because it is not aware
whether the device is behind an IOMMU.

If I'm understand right, it seems like that swiotlb-xen is not ready to work properly in case
when we retrieved MFN instead of proper GFN mapped to Dom0 memory.
Maybe you know some ideas to overcome this condition?

swiotlb-xen work as intended. You have a DMA buffer at an address that your device cannot deal with. So it will try to bounce it.

 As the address is too high to be handled by the device, swiotlb will try
 to bounce it. I think it is correct to bounce the page but I am not sure
 why it can't. What the size of the DMA transaction?

The DMA map size is 3686400 bytes.

So that's a 3MB buffer. I am slightly confused because in an earlier message you wrote that the memory is coming from the guest. How did you map it?

I've added several logs to swiotlb map_single() and see:
[  151.298455] <SWIOTLB> swiotlb_tbl_map_single() origin_addr: 64af97000, needed: 708,
avail: 7fc0, stride: 2, index: 4160

I am not sure how to read the logs... Are the number in hexadecimal or decimal? It might be useful if you post the diff of your changes.


Swiotlb did not fit requested slots because the maximum slot size equals IO_TLB_SEGSIZE=128 by default.

Ok. So it sounds like your problem is the have a DMA buffer that is too large for the default swiotlb. Did you try to bump the value from the command line?

But I think, we cannot use64af97000 address in the swiotlb_bounce() directly.

I am not sure to understand what you mean. Can you clarify?



Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.