Alex Williamson
2018-Feb-14 15:26 UTC
[PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu
On Wed, 14 Feb 2018 14:53:40 +0000 Jean-Philippe Brucker <jean-philippe.brucker at arm.com> wrote:> When enabling both VFIO and VIRTIO_IOMMU modules, automatically select > VFIO_IOMMU_TYPE1 as well. > > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> > --- > drivers/vfio/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > index c84333eb5eb5..65a1e691110c 100644 > --- a/drivers/vfio/Kconfig > +++ b/drivers/vfio/Kconfig > @@ -21,7 +21,7 @@ config VFIO_VIRQFD > menuconfig VFIO > tristate "VFIO Non-Privileged userspace driver framework" > depends on IOMMU_API > - select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3) > + select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3 || VIRTIO_IOMMU) > select ANON_INODES > help > VFIO provides a framework for secure userspace device drivers.Why are we basing this on specific IOMMU drivers in the first place? Only ARM is doing that. Shouldn't IOMMU_API only be enabled for ARM targets that support it and therefore we can forget about the specific IOMMU drivers? Thanks, Alex
Robin Murphy
2018-Feb-14 15:35 UTC
[PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu
On 14/02/18 15:26, Alex Williamson wrote:> On Wed, 14 Feb 2018 14:53:40 +0000 > Jean-Philippe Brucker <jean-philippe.brucker at arm.com> wrote: > >> When enabling both VFIO and VIRTIO_IOMMU modules, automatically select >> VFIO_IOMMU_TYPE1 as well. >> >> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> >> --- >> drivers/vfio/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig >> index c84333eb5eb5..65a1e691110c 100644 >> --- a/drivers/vfio/Kconfig >> +++ b/drivers/vfio/Kconfig >> @@ -21,7 +21,7 @@ config VFIO_VIRQFD >> menuconfig VFIO >> tristate "VFIO Non-Privileged userspace driver framework" >> depends on IOMMU_API >> - select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3) >> + select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3 || VIRTIO_IOMMU) >> select ANON_INODES >> help >> VFIO provides a framework for secure userspace device drivers. > > Why are we basing this on specific IOMMU drivers in the first place? > Only ARM is doing that. Shouldn't IOMMU_API only be enabled for ARM > targets that support it and therefore we can forget about the specific > IOMMU drivers? Thanks,Makes sense - the majority of ARM systems (and mobile/embedded ARM64 ones) making use of IOMMU_API won't actually support VFIO, but it can't hurt to allow them to select the type 1 driver regardless. Especially as multiplatform configs are liable to be pulling in the SMMU driver(s) anyway. Robin.
Jean-Philippe Brucker
2018-Feb-15 13:53 UTC
[PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu
On 14/02/18 15:35, Robin Murphy wrote:> On 14/02/18 15:26, Alex Williamson wrote: >> On Wed, 14 Feb 2018 14:53:40 +0000 >> Jean-Philippe Brucker <jean-philippe.brucker at arm.com> wrote: >> >>> When enabling both VFIO and VIRTIO_IOMMU modules, automatically select >>> VFIO_IOMMU_TYPE1 as well. >>> >>> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> >>> --- >>> drivers/vfio/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig >>> index c84333eb5eb5..65a1e691110c 100644 >>> --- a/drivers/vfio/Kconfig >>> +++ b/drivers/vfio/Kconfig >>> @@ -21,7 +21,7 @@ config VFIO_VIRQFD >>> menuconfig VFIO >>> tristate "VFIO Non-Privileged userspace driver framework" >>> depends on IOMMU_API >>> - select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3) >>> + select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3 || VIRTIO_IOMMU) >>> select ANON_INODES >>> help >>> VFIO provides a framework for secure userspace device drivers. >> >> Why are we basing this on specific IOMMU drivers in the first place? >> Only ARM is doing that. Shouldn't IOMMU_API only be enabled for ARM >> targets that support it and therefore we can forget about the specific >> IOMMU drivers? Thanks, > > Makes sense - the majority of ARM systems (and mobile/embedded ARM64 > ones) making use of IOMMU_API won't actually support VFIO, but it can't > hurt to allow them to select the type 1 driver regardless. Especially as > multiplatform configs are liable to be pulling in the SMMU driver(s) anyway.Cool, then I'll change that line to: + select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM || ARM64) Thanks, Jean
Apparently Analagous Threads
- [PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu
- [PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu
- [PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu
- [PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU
- [PATCH] iommu/virtio: Build virtio-iommu as module