On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 01:22:44PM +0000, Robin Murphy wrote:
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
With the built-in topology description in place, x86 platforms can now
use the virtio-iommu.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx>
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 068d4e0e3541..adcbda44d473 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -508,8 +508,9 @@ config HYPERV_IOMMU
config VIRTIO_IOMMU
bool "Virtio IOMMU driver"
depends on VIRTIO=y
- depends on ARM64
+ depends on (ARM64 || X86)
select IOMMU_API
+ select IOMMU_DMA
Can that have an "if X86" for clarity? AIUI it's not necessary for
virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
right?
Robin.
In fact does not this work on any platform now?
There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
has been converted recently [1] but VT-d still implements its own DMA ops
(conversion patches are on the list [2]). On Arm the arch Kconfig selects
IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
complete. Until then I can add a "if X86" here for clarity.
Thanks,
Jean
[1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@xxxxxx/
[2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@xxxxxx/
What about others? E.g. PPC?
That was the point I was getting at - while iommu-dma should build just fine
for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code
to correctly wire up iommu_dma_ops to devices. Thus there's currently no
point pulling it in and pretending it's anything more than a waste of space
for architectures other than arm64 and x86. It's merely a historical
artefact of the x86 DMA API implementation that when the IOMMU drivers were
split out to form drivers/iommu they took some of their relevant arch code
with them.
Robin.
Rather than white-listing architectures, how about making the
architectures in question set some kind of symbol, and depend on it?
Umm, that's basically what we have already? Architectures that use
iommu_dma_ops select IOMMU_DMA.
The only issue is the oddity of x86 treating IOMMU drivers as part of
its arch code, which has never come up against a cross-architecture
driver until now. Hence the options of either maintaining that paradigm
and having the 'x86 arch code' aspect of this driver "select IOMMU_DMA
if x86" such that it works out equivalent to AMD_IOMMU, or a more
involved cleanup to move that responsibility out of
drivers/iommu/Kconfig entirely and have arch/x86/Kconfig do something
like "select IOMMU_DMA if IOMMU_API", as Jean suggested up-thread.
In the specific context of IOMMU_DMA we're not talking about any kind of
white-list, merely a one-off special case for one particular architecture.
Robin.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
