diff mbox

[1/7] VFIO_IOMMU_TYPE1 workaround to build for platform devices

Message ID 1380554923-17818-2-git-send-email-a.motakis@virtualopensystems.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Antonios Motakis Sept. 30, 2013, 3:28 p.m. UTC
This is a workaround to make the VFIO_IOMMU_TYPE1 driver usable with
platform devices instead of PCI. A future permanent fix should support
both. This is required in order to use the Exynos SMMU, or ARM SMMU
driver with VFIO.

Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
---
 drivers/vfio/Kconfig            |  2 +-
 drivers/vfio/vfio_iommu_type1.c | 22 ++++++++++++++++++----
 2 files changed, 19 insertions(+), 5 deletions(-)

Comments

Alex Williamson Sept. 30, 2013, 5:39 p.m. UTC | #1
On Mon, 2013-09-30 at 17:28 +0200, Antonios Motakis wrote:
> This is a workaround to make the VFIO_IOMMU_TYPE1 driver usable with
> platform devices instead of PCI. A future permanent fix should support
> both. This is required in order to use the Exynos SMMU, or ARM SMMU
> driver with VFIO.
> 
> Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
> ---
>  drivers/vfio/Kconfig            |  2 +-
>  drivers/vfio/vfio_iommu_type1.c | 22 ++++++++++++++++++----
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 7cd5dec..1f84eda 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -6,7 +6,7 @@ config VFIO_IOMMU_TYPE1
>  menuconfig VFIO
>  	tristate "VFIO Non-Privileged userspace driver framework"
>  	depends on IOMMU_API
> -	select VFIO_IOMMU_TYPE1 if X86
> +	select VFIO_IOMMU_TYPE1 if X86 || ARM
>  	help
>  	  VFIO provides a framework for secure userspace device drivers.
>  	  See Documentation/vfio.txt for more details.
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 6f3fbc4..d7e6a12 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -30,7 +30,8 @@
>  #include <linux/iommu.h>
>  #include <linux/module.h>
>  #include <linux/mm.h>
> -#include <linux/pci.h>		/* pci_bus_type */
> +#include <linux/pci.h>			/* pci_bus_type */
> +#include <linux/platform_device.h>	/* platform_bus_type */
>  #include <linux/sched.h>
>  #include <linux/slab.h>
>  #include <linux/uaccess.h>
> @@ -46,6 +47,8 @@ module_param_named(allow_unsafe_interrupts,
>  		   allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(allow_unsafe_interrupts,
>  		 "Enable VFIO IOMMU support for on platforms without interrupt remapping support.");
> +static struct bus_type *iommu_bus_type = NULL;
> +static bool require_cap_intr_remap = false;
>  
>  struct vfio_iommu {
>  	struct iommu_domain	*domain;
> @@ -612,7 +615,8 @@ static void *vfio_iommu_type1_open(unsigned long arg)
>  	/*
>  	 * Wish we didn't have to know about bus_type here.
>  	 */
> -	iommu->domain = iommu_domain_alloc(&pci_bus_type);
> +	iommu->domain = iommu_domain_alloc(iommu_bus_type);
> +
>  	if (!iommu->domain) {
>  		kfree(iommu);
>  		return ERR_PTR(-EIO);
> @@ -624,7 +628,7 @@ static void *vfio_iommu_type1_open(unsigned long arg)
>  	 * the way.  Fortunately we know interrupt remapping is global for
>  	 * our iommus.
>  	 */
> -	if (!allow_unsafe_interrupts &&
> +	if (require_cap_intr_remap && !allow_unsafe_interrupts &&
>  	    !iommu_domain_has_cap(iommu->domain, IOMMU_CAP_INTR_REMAP)) {
>  		pr_warn("%s: No interrupt remapping support.  Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
>  		       __func__);
> @@ -733,7 +737,17 @@ static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
>  
>  static int __init vfio_iommu_type1_init(void)
>  {
> -	if (!iommu_present(&pci_bus_type))
> +#ifdef CONFIG_PCI
> +	if (iommu_present(&pci_bus_type)) {
> +		iommu_bus_type = &pci_bus_type;
> +		/* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
> +		require_cap_intr_remap = true;
> +	}
> +#endif
> +	if (!iommu_bus_type && iommu_present(&platform_bus_type))
> +		iommu_bus_type = &platform_bus_type;
> +
> +	if(!iommu_bus_type)
>  		return -ENODEV;
>  
>  	return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);

Is it possible to have a system with both PCI and platform devices?  How
would you support that?  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Antonios Motakis Oct. 1, 2013, 9:36 a.m. UTC | #2
On Mon, Sep 30, 2013 at 7:39 PM, Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> On Mon, 2013-09-30 at 17:28 +0200, Antonios Motakis wrote:
> > This is a workaround to make the VFIO_IOMMU_TYPE1 driver usable with
> > platform devices instead of PCI. A future permanent fix should support
> > both. This is required in order to use the Exynos SMMU, or ARM SMMU
> > driver with VFIO.
> >
> > Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
> > ---
> >  drivers/vfio/Kconfig            |  2 +-
> >  drivers/vfio/vfio_iommu_type1.c | 22 ++++++++++++++++++----
> >  2 files changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> > index 7cd5dec..1f84eda 100644
> > --- a/drivers/vfio/Kconfig
> > +++ b/drivers/vfio/Kconfig
> > @@ -6,7 +6,7 @@ config VFIO_IOMMU_TYPE1
> >  menuconfig VFIO
> >       tristate "VFIO Non-Privileged userspace driver framework"
> >       depends on IOMMU_API
> > -     select VFIO_IOMMU_TYPE1 if X86
> > +     select VFIO_IOMMU_TYPE1 if X86 || ARM
> >       help
> >         VFIO provides a framework for secure userspace device drivers.
> >         See Documentation/vfio.txt for more details.
> > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> > index 6f3fbc4..d7e6a12 100644
> > --- a/drivers/vfio/vfio_iommu_type1.c
> > +++ b/drivers/vfio/vfio_iommu_type1.c
> > @@ -30,7 +30,8 @@
> >  #include <linux/iommu.h>
> >  #include <linux/module.h>
> >  #include <linux/mm.h>
> > -#include <linux/pci.h>               /* pci_bus_type */
> > +#include <linux/pci.h>                       /* pci_bus_type */
> > +#include <linux/platform_device.h>   /* platform_bus_type */
> >  #include <linux/sched.h>
> >  #include <linux/slab.h>
> >  #include <linux/uaccess.h>
> > @@ -46,6 +47,8 @@ module_param_named(allow_unsafe_interrupts,
> >                  allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
> >  MODULE_PARM_DESC(allow_unsafe_interrupts,
> >                "Enable VFIO IOMMU support for on platforms without interrupt remapping support.");
> > +static struct bus_type *iommu_bus_type = NULL;
> > +static bool require_cap_intr_remap = false;
> >
> >  struct vfio_iommu {
> >       struct iommu_domain     *domain;
> > @@ -612,7 +615,8 @@ static void *vfio_iommu_type1_open(unsigned long arg)
> >       /*
> >        * Wish we didn't have to know about bus_type here.
> >        */
> > -     iommu->domain = iommu_domain_alloc(&pci_bus_type);
> > +     iommu->domain = iommu_domain_alloc(iommu_bus_type);
> > +
> >       if (!iommu->domain) {
> >               kfree(iommu);
> >               return ERR_PTR(-EIO);
> > @@ -624,7 +628,7 @@ static void *vfio_iommu_type1_open(unsigned long arg)
> >        * the way.  Fortunately we know interrupt remapping is global for
> >        * our iommus.
> >        */
> > -     if (!allow_unsafe_interrupts &&
> > +     if (require_cap_intr_remap && !allow_unsafe_interrupts &&
> >           !iommu_domain_has_cap(iommu->domain, IOMMU_CAP_INTR_REMAP)) {
> >               pr_warn("%s: No interrupt remapping support.  Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
> >                      __func__);
> > @@ -733,7 +737,17 @@ static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
> >
> >  static int __init vfio_iommu_type1_init(void)
> >  {
> > -     if (!iommu_present(&pci_bus_type))
> > +#ifdef CONFIG_PCI
> > +     if (iommu_present(&pci_bus_type)) {
> > +             iommu_bus_type = &pci_bus_type;
> > +             /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
> > +             require_cap_intr_remap = true;
> > +     }
> > +#endif
> > +     if (!iommu_bus_type && iommu_present(&platform_bus_type))
> > +             iommu_bus_type = &platform_bus_type;
> > +
> > +     if(!iommu_bus_type)
> >               return -ENODEV;
> >
> >       return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);
>
> Is it possible to have a system with both PCI and platform devices?  How
> would you support that?  Thanks,
>
> Alex
>

It looks like it would take more work to support IOMMUs on both at the
same time, esp. since we need to know the right bus type.

However, I don't know of a system with an IOMMU on both PCI and a
platform bus. A better solution might be found before we can talk
about upstreaming, of course.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yoder Stuart-B08248 Oct. 1, 2013, 7:21 p.m. UTC | #3
> >  static int __init vfio_iommu_type1_init(void)

> >  {

> > -	if (!iommu_present(&pci_bus_type))

> > +#ifdef CONFIG_PCI

> > +	if (iommu_present(&pci_bus_type)) {

> > +		iommu_bus_type = &pci_bus_type;

> > +		/* For PCI targets, IOMMU_CAP_INTR_REMAP is required */

> > +		require_cap_intr_remap = true;

> > +	}

> > +#endif

> > +	if (!iommu_bus_type && iommu_present(&platform_bus_type))

> > +		iommu_bus_type = &platform_bus_type;

> > +

> > +	if(!iommu_bus_type)

> >  		return -ENODEV;

> >

> >  	return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);

> 

> Is it possible to have a system with both PCI and platform devices?  How

> would you support that?  Thanks,


It most certainly is a requirement to support both.  This is how
all of our (FSL) SoCs will expect to work.

I need to understand better why 'iommu_bus_type' exists at
all...

Stuart
Antonios Motakis Oct. 2, 2013, 11:13 a.m. UTC | #4
On Tue, Oct 1, 2013 at 9:21 PM, Yoder Stuart-B08248
<B08248@freescale.com> wrote:
>> >  static int __init vfio_iommu_type1_init(void)
>> >  {
>> > -   if (!iommu_present(&pci_bus_type))
>> > +#ifdef CONFIG_PCI
>> > +   if (iommu_present(&pci_bus_type)) {
>> > +           iommu_bus_type = &pci_bus_type;
>> > +           /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
>> > +           require_cap_intr_remap = true;
>> > +   }
>> > +#endif
>> > +   if (!iommu_bus_type && iommu_present(&platform_bus_type))
>> > +           iommu_bus_type = &platform_bus_type;
>> > +
>> > +   if(!iommu_bus_type)
>> >             return -ENODEV;
>> >
>> >     return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);
>>
>> Is it possible to have a system with both PCI and platform devices?  How
>> would you support that?  Thanks,
>
> It most certainly is a requirement to support both.  This is how
> all of our (FSL) SoCs will expect to work.
>

Both with an IOMMU present?

> I need to understand better why 'iommu_bus_type' exists at
> all...

It exists because the API expects to know the bus type. Ideally, this
would be solved at the IOMMU API level, and we would be able to be
completely bus agnostic in the TYPE1 driver.

>
> Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alexander Graf Oct. 2, 2013, 12:14 p.m. UTC | #5
On 01.10.2013, at 21:21, Yoder Stuart-B08248 wrote:

>>> static int __init vfio_iommu_type1_init(void)
>>> {
>>> -	if (!iommu_present(&pci_bus_type))
>>> +#ifdef CONFIG_PCI
>>> +	if (iommu_present(&pci_bus_type)) {
>>> +		iommu_bus_type = &pci_bus_type;
>>> +		/* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
>>> +		require_cap_intr_remap = true;
>>> +	}
>>> +#endif
>>> +	if (!iommu_bus_type && iommu_present(&platform_bus_type))
>>> +		iommu_bus_type = &platform_bus_type;
>>> +
>>> +	if(!iommu_bus_type)
>>> 		return -ENODEV;
>>> 
>>> 	return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);
>> 
>> Is it possible to have a system with both PCI and platform devices?  How
>> would you support that?  Thanks,
> 
> It most certainly is a requirement to support both.  This is how
> all of our (FSL) SoCs will expect to work.

I thought the PCI bus emits a cookie that the system wide IOMMU can then use to differentiate the origin of the transaction? So the same IOMMU can be used for PCI as well as platform routing.


Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yoder Stuart-B08248 Oct. 2, 2013, 12:55 p.m. UTC | #6
> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis@virtualopensystems.com]
> Sent: Wednesday, October 02, 2013 6:14 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; kvmarm@lists.cs.columbia.edu; iommu@lists.linux-
> foundation.org; linux-samsung-soc@vger.kernel.org; kvm@vger.kernel.org;
> agraf@suse.de; tech@virtualopensystems.com; kim.phillips@linaro.org
> Subject: Re: [PATCH 1/7] VFIO_IOMMU_TYPE1 workaround to build for
> platform devices
> 
> On Tue, Oct 1, 2013 at 9:21 PM, Yoder Stuart-B08248
> <B08248@freescale.com> wrote:
> >> >  static int __init vfio_iommu_type1_init(void)
> >> >  {
> >> > -   if (!iommu_present(&pci_bus_type))
> >> > +#ifdef CONFIG_PCI
> >> > +   if (iommu_present(&pci_bus_type)) {
> >> > +           iommu_bus_type = &pci_bus_type;
> >> > +           /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
> >> > +           require_cap_intr_remap = true;
> >> > +   }
> >> > +#endif
> >> > +   if (!iommu_bus_type && iommu_present(&platform_bus_type))
> >> > +           iommu_bus_type = &platform_bus_type;
> >> > +
> >> > +   if(!iommu_bus_type)
> >> >             return -ENODEV;
> >> >
> >> >     return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);
> >>
> >> Is it possible to have a system with both PCI and platform devices?
> How
> >> would you support that?  Thanks,
> >
> > It most certainly is a requirement to support both.  This is how
> > all of our (FSL) SoCs will expect to work.
> >
> 
> Both with an IOMMU present?

Yes.  We expect to be able to pass through PCI devices and
platform devices at the same time...all with IOMMU isolation.

Stuart

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Donald Dutile Oct. 29, 2013, 1:17 a.m. UTC | #7
On 10/02/2013 08:14 AM, Alexander Graf wrote:
>
> On 01.10.2013, at 21:21, Yoder Stuart-B08248 wrote:
>
>>>> static int __init vfio_iommu_type1_init(void)
>>>> {
>>>> -	if (!iommu_present(&pci_bus_type))
>>>> +#ifdef CONFIG_PCI
>>>> +	if (iommu_present(&pci_bus_type)) {
>>>> +		iommu_bus_type =&pci_bus_type;
>>>> +		/* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
>>>> +		require_cap_intr_remap = true;
>>>> +	}
>>>> +#endif
>>>> +	if (!iommu_bus_type&&  iommu_present(&platform_bus_type))
>>>> +		iommu_bus_type =&platform_bus_type;
>>>> +
>>>> +	if(!iommu_bus_type)
>>>> 		return -ENODEV;
>>>>
>>>> 	return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);
>>>
>>> Is it possible to have a system with both PCI and platform devices?  How
>>> would you support that?  Thanks,
>>
>> It most certainly is a requirement to support both.  This is how
>> all of our (FSL) SoCs will expect to work.
>
> I thought the PCI bus emits a cookie that the system wide IOMMU can then use to differentiate the origin of the transaction? So the same IOMMU can be used for PCI as well as platform routing.
>
*can* be the same IOMMU, yes;
have to, no, so there can be multiple IOMMUs of different types.

>
> Alex
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yoder Stuart-B08248 Oct. 29, 2013, 3:57 p.m. UTC | #8
> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis@virtualopensystems.com]
> Sent: Wednesday, October 02, 2013 6:14 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; kvmarm@lists.cs.columbia.edu; iommu@lists.linux-
> foundation.org; linux-samsung-soc@vger.kernel.org; kvm@vger.kernel.org;
> agraf@suse.de; tech@virtualopensystems.com; kim.phillips@linaro.org
> Subject: Re: [PATCH 1/7] VFIO_IOMMU_TYPE1 workaround to build for
> platform devices
> 
> On Tue, Oct 1, 2013 at 9:21 PM, Yoder Stuart-B08248
> <B08248@freescale.com> wrote:
> >> >  static int __init vfio_iommu_type1_init(void)
> >> >  {
> >> > -   if (!iommu_present(&pci_bus_type))
> >> > +#ifdef CONFIG_PCI
> >> > +   if (iommu_present(&pci_bus_type)) {
> >> > +           iommu_bus_type = &pci_bus_type;
> >> > +           /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
> >> > +           require_cap_intr_remap = true;
> >> > +   }
> >> > +#endif
> >> > +   if (!iommu_bus_type && iommu_present(&platform_bus_type))
> >> > +           iommu_bus_type = &platform_bus_type;
> >> > +
> >> > +   if(!iommu_bus_type)
> >> >             return -ENODEV;
> >> >
> >> >     return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);
> >>
> >> Is it possible to have a system with both PCI and platform devices?
> How
> >> would you support that?  Thanks,
> >
> > It most certainly is a requirement to support both.  This is how
> > all of our (FSL) SoCs will expect to work.
> >
> 
> Both with an IOMMU present?

Yes.

Stuart

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 7cd5dec..1f84eda 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -6,7 +6,7 @@  config VFIO_IOMMU_TYPE1
 menuconfig VFIO
 	tristate "VFIO Non-Privileged userspace driver framework"
 	depends on IOMMU_API
-	select VFIO_IOMMU_TYPE1 if X86
+	select VFIO_IOMMU_TYPE1 if X86 || ARM
 	help
 	  VFIO provides a framework for secure userspace device drivers.
 	  See Documentation/vfio.txt for more details.
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 6f3fbc4..d7e6a12 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -30,7 +30,8 @@ 
 #include <linux/iommu.h>
 #include <linux/module.h>
 #include <linux/mm.h>
-#include <linux/pci.h>		/* pci_bus_type */
+#include <linux/pci.h>			/* pci_bus_type */
+#include <linux/platform_device.h>	/* platform_bus_type */
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/uaccess.h>
@@ -46,6 +47,8 @@  module_param_named(allow_unsafe_interrupts,
 		   allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(allow_unsafe_interrupts,
 		 "Enable VFIO IOMMU support for on platforms without interrupt remapping support.");
+static struct bus_type *iommu_bus_type = NULL;
+static bool require_cap_intr_remap = false;
 
 struct vfio_iommu {
 	struct iommu_domain	*domain;
@@ -612,7 +615,8 @@  static void *vfio_iommu_type1_open(unsigned long arg)
 	/*
 	 * Wish we didn't have to know about bus_type here.
 	 */
-	iommu->domain = iommu_domain_alloc(&pci_bus_type);
+	iommu->domain = iommu_domain_alloc(iommu_bus_type);
+
 	if (!iommu->domain) {
 		kfree(iommu);
 		return ERR_PTR(-EIO);
@@ -624,7 +628,7 @@  static void *vfio_iommu_type1_open(unsigned long arg)
 	 * the way.  Fortunately we know interrupt remapping is global for
 	 * our iommus.
 	 */
-	if (!allow_unsafe_interrupts &&
+	if (require_cap_intr_remap && !allow_unsafe_interrupts &&
 	    !iommu_domain_has_cap(iommu->domain, IOMMU_CAP_INTR_REMAP)) {
 		pr_warn("%s: No interrupt remapping support.  Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
 		       __func__);
@@ -733,7 +737,17 @@  static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
 
 static int __init vfio_iommu_type1_init(void)
 {
-	if (!iommu_present(&pci_bus_type))
+#ifdef CONFIG_PCI
+	if (iommu_present(&pci_bus_type)) {
+		iommu_bus_type = &pci_bus_type;
+		/* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
+		require_cap_intr_remap = true;
+	}
+#endif
+	if (!iommu_bus_type && iommu_present(&platform_bus_type))
+		iommu_bus_type = &platform_bus_type;
+
+	if(!iommu_bus_type)
 		return -ENODEV;
 
 	return vfio_register_iommu_driver(&vfio_iommu_driver_ops_type1);