| Message ID | cover.1626888444.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iommu: Refactor DMA domain strictness | expand |
On 21/07/2021 19:20, Robin Murphy wrote: > Hi all, > > First off, yes, this conflicts with just about everything else > currently in-flight. Sorry about that. If it stands up to initial review > then I'll start giving some thought to how to fit everything together > (particularly John's cleanup of strictness defaults, which I'd be > inclined to fold into a v2 of this series). It seems to me that patch #20 is the only real conflict, and that is just a different form of mine in that passthrough, strict, and lazy are under a single choice, as opposed to passthrough being a separate config (for mine). And on that point, I did assume that we would have a different sysfs file for strict vs lazy in this series, and not a new domain type. But I assume that there is a good reason for that. Anyway, I'd really like to see my series just merged now. Thanks, John > > Anyway, this is my take on promoting the strict vs. non-strict DMA > domain choice to distinct domain types, so that it can fit logically > into the existing sysfs and Kconfig controls. The first 13 patches are > effectively preparatory cleanup to reduce churn in the later changes, > but could be merged in their own right even if the rest is too > contentious. I ended up splitting patches #2-#11 by driver for ease of > review, since some of them are more than just trivial deletions, but > they could readily be squashed (even as far as with #1 and #12 too). > > I'm slightly surprised at how straightforward it's turned out, but it > has survived some very basic smoke testing for arm-smmu using dmatest > on my Arm Juno board. Branch here for convenience:
On 2021-07-26 09:13, John Garry wrote: > On 21/07/2021 19:20, Robin Murphy wrote: >> Hi all, >> >> First off, yes, this conflicts with just about everything else >> currently in-flight. Sorry about that. If it stands up to initial review >> then I'll start giving some thought to how to fit everything together >> (particularly John's cleanup of strictness defaults, which I'd be >> inclined to fold into a v2 of this series). > > It seems to me that patch #20 is the only real conflict, and that is > just a different form of mine in that passthrough, strict, and lazy are > under a single choice, as opposed to passthrough being a separate config > (for mine). And on that point, I did assume that we would have a > different sysfs file for strict vs lazy in this series, and not a new > domain type. But I assume that there is a good reason for that. Yes, as mentioned by patch #18 it helps a surprising number of things fall into place really neatly. > Anyway, I'd really like to see my series just merged now. Sure, I was going to say I can happily rebase on top of your series as-is if Joerg wants to apply it first, and now that's just happened :) Cheers, Robin.
Hi Robin, On Wed, Jul 21, 2021 at 07:20:11PM +0100, Robin Murphy wrote: > Robin Murphy (23): > iommu: Pull IOVA cookie management into the core > iommu/amd: Drop IOVA cookie management > iommu/arm-smmu: Drop IOVA cookie management > iommu/vt-d: Drop IOVA cookie management > iommu/exynos: Drop IOVA cookie management > iommu/ipmmu-vmsa: Drop IOVA cookie management > iommu/mtk: Drop IOVA cookie management > iommu/rockchip: Drop IOVA cookie management > iommu/sprd: Drop IOVA cookie management > iommu/sun50i: Drop IOVA cookie management > iommu/virtio: Drop IOVA cookie management > iommu/dma: Unexport IOVA cookie management > iommu/dma: Remove redundant "!dev" checks > iommu: Introduce explicit type for non-strict DMA domains > iommu/amd: Prepare for multiple DMA domain types > iommu/arm-smmu: Prepare for multiple DMA domain types > iommu/vt-d: Prepare for multiple DMA domain types > iommu: Express DMA strictness via the domain type > iommu: Expose DMA domain strictness via sysfs > iommu: Allow choosing DMA strictness at build time > iommu/dma: Factor out flush queue init > iommu: Allow enabling non-strict mode dynamically > iommu/arm-smmu: Allow non-strict in pgtable_quirks interface I really like this patch-set. It is a nice cleanup and the implementation is straightforward. Given no other major objections and reviews I think this is material for 5.15. Thanks, Joerg