On 27/07/18 15:10, Dmitry Osipenko wrote:
On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
The proposed solution adds a new option to the base device driver
structure that allows device drivers to explicitly convey to the drivers
core that the implicit IOMMU backing for devices must not happen.
Why is IOMMU mapping a problem for the Tegra GPU driver?
If we add something like this then it should not be the choice of the
device driver, but of the user and/or the firmware.
Agreed, and it would still need somebody to configure an identity domain so
that transactions aren't aborted immediately. We currently allow the
identity domain to be used by default via a command-line option, so I guess
we'd need a way for firmware to request that on a per-device basis.
The IOMMU mapping itself is not a problem, the problem is the management of
the IOMMU. For Tegra we don't want anything to intrude into the IOMMU
activities because:
1) GPU HW require additional configuration for the IOMMU usage and dumb
mapping of the allocations simply doesn't work.
Generally, that's already handled by the DRM drivers allocating their
own unmanaged domains. The only problem we really need to solve in that
regard is that currently the device DMA ops don't get updated when
moving away from the managed domain. That's been OK for the VFIO case
where the device is bound to a different driver which we know won't make
any explicit DMA API calls, but for the more general case of IOMMU-aware
drivers we could certainly do with a bit of cooperation between the
IOMMU API, DMA API, and arch code to update the DMA ops dynamically to
cope with intermediate subsystems making DMA API calls on behalf of
devices they don't know the intimate details of.
2) Older Tegra generations have a limited resource and capabilities in regards
to IOMMU usage, allocating IOMMU domain per-device is just impossible for
example.
3) HW performs context switches and so particular allocations have to be
assigned to a particular contexts IOMMU domain.
I understand Qualcomm SoCs have a similar thing too, and AFAICS that
case just doesn't fit into the current API model at all. We need the
IOMMU driver to somehow know about the specific details of which devices
have magic associations with specific contexts, and we almost certainly
need a more expressive interface than iommu_domain_alloc() to have any
hope of reliable results.
Robin.
Some of the above is due to a SW driver model (and its work-in-progress
status), other is due to a HW model. So essentially we need a way for a driver
to tell the core not to mess with IOMMU stuff of drivers device behind the
drivers back.
I'm not sure what you guys are meaning by the "firmware", could you elaborate
please? Do you mean the Open Firmware and hence the devicetree or what?
_______________________________________________
iommu mailing list
iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
