linux-kernel - dma api errors with swiotlb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <e3c4b2e1-7518-ab0e-a6ce-3fae9903dac0@shipmail.org>
Date:   Wed, 4 Sep 2019 09:59:08 +0200
From:   Thomas Hellström (VMware) 
        <thomas_os@...pmail.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: dma api errors with swiotlb

Hi, Cristoph.

Another DMA related question before I start to post patches in this area 
again..

Our virtual SCSI device (which BTW is fully DMA compliant) has a large 
queue depth and therefore runs out of SWIOTLB space => The scsi middle 
layer behaves nicely and asks the driver to retry the dma mapping 
operation. All fine.

The problem is that while this happens, the kernel log spits out a 
number of dma- and SWIOTLB errors, which are really harmless.

While one could probably just say go and increase the SWIOTLB size, but 
on some systems that might not be doable.

We could reduce the queue depth when SEV is active, which is probably 
one of those hacky solutions you dislike.

We could silence the dma- and swiotlb errors? At least selectively for 
some devices?

Do you have any guidance into the best solution here?

Thanks,
Thomas.