On Mon, Jan 06, 2020 at 05:34:00PM +0000, Robin Murphy wrote: > On 01/01/2020 1:54 am, David Rientjes via iommu wrote: >> Christoph, Thomas, is something like this (without the diagnosic >> information included in this patch) acceptable for these allocations? >> Adding expansion support when the pool is half depleted wouldn't be *that* >> hard. >> >> Or are there alternatives we should consider? Thanks! > > Are there any platforms which require both non-cacheable remapping *and* > unencrypted remapping for distinct subsets of devices? > > If not (and I'm assuming there aren't, because otherwise this patch is > incomplete in covering only 2 of the 3 possible combinations), then > couldn't we keep things simpler by just attributing both properties to the > single "atomic pool" on the basis that one or the other will always be a > no-op? In other words, basically just tweaking the existing "!coherent" > tests to "!coherent || force_dma_unencrypted()" and doing > set_dma_unencrypted() unconditionally in atomic_pool_init().
I think that would make most sense. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
