On 2021-03-26 17:26, Mark Kettenis wrote:
From: Arnd Bergmann <arnd@xxxxxxxxxx>
Date: Fri, 26 Mar 2021 17:38:24 +0100
On Fri, Mar 26, 2021 at 5:10 PM Sven Peter <sven@xxxxxxxxxxxxx> wrote:
On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
Some of the DARTs provide a bypass facility. That code make using the
standard "dma-ranges" property tricky. That property would need to
contain the bypass address range. But that would mean that if the
DART driver needs to look at that property to figure out the address
range that supports translation it will need to be able to distinguish
between the translatable address range and the bypass address range.
Do we understand if and why we even need to bypass certain streams?
My guess is that this is a performance optimization.
There are generally three reasons to want an iommu in the first place:
- Pass a device down to a guest or user process without giving
access to all of memory
- Avoid problems with limitations in the device, typically when it
only supports
32-bit bus addressing, but the installed memory is larger than 4GB
- Protect kernel memory from broken drivers
If you care about none of the above, but you do care about data transfer
speed, you are better off just leaving the IOMMU in bypass mode.
I don't think we have to support it if the IOMMU works reliably, but it's
something that users might want.
Another reason might be that a device needs access to large amounts of
physical memory at the same time and the 32-bit address space that the
DART provides is too tight.
In U-Boot I might want to use bypass where it works since there is no
proper IOMMU support in U-Boot. Generally speaking, the goal is to
keep the code size down in U-Boot. In OpenBSD I'll probably avoid
bypass mode if I can.
I haven't figured out how the bypass stuff really works. Corellium
added support for it in their codebase when they added support for
Thunderbolt, and some of the DARTs that seem to be related to
Thunderbolt do indeed have a "bypass" property. But it is unclear to
me how the different puzzle pieces fit together for Thunderbolt.
Anyway, from my viewpoint having the information about the IOVA
address space sit on the devices makes little sense. This information
is needed by the DART driver, and there is no direct cnnection from
the DART to the individual devices in the devicetree. The "iommus"
property makes a connection in the opposite direction.
What still seems unclear is whether these addressing limitations are a
property of the DART input interface, the device output interface, or
the interconnect between them. Although the observable end result
appears more or less the same either way, they are conceptually
different things which we have different abstractions to deal with.
Robin.
