[v6,08/26] intel_iommu: provide helper function vtd_get_iommu

Moves acpi_get_iommu() under VT-d to make it a public function.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 hw/i386/acpi-build.c          |  7 +------
 hw/i386/intel_iommu.c         | 13 +++++++++++++
 include/hw/i386/intel_iommu.h |  2 ++
 3 files changed, 16 insertions(+), 6 deletions(-)

On Thu, May 5, 2016 at 6:25 AM, Peter Xu <peterx@redhat.com> wrote:
> Moves acpi_get_iommu() under VT-d to make it a public function.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  hw/i386/acpi-build.c          |  7 +------
>  hw/i386/intel_iommu.c         | 13 +++++++++++++
>  include/hw/i386/intel_iommu.h |  2 ++
>  3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 5d2d87b..b064bc2 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2677,12 +2677,7 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
>
>  static bool acpi_has_iommu(void)
>  {
> -    bool ambiguous;
> -    Object *intel_iommu;
> -
> -    intel_iommu = object_resolve_path_type("", TYPE_INTEL_IOMMU_DEVICE,
> -                                           &ambiguous);
> -    return intel_iommu && !ambiguous;
> +    return !!vtd_iommu_get();
>  }

This is not consistent with what we have in the AMD IOMMU patches but
I guess this could be easily fixed.

>
>  static
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 4d14124..a44289f 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -2001,6 +2001,19 @@ VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn)
>      return vtd_dev_as;
>  }
>
> +IntelIOMMUState *vtd_iommu_get(void)
> +{
> +    bool ambiguous = false;
> +    Object *intel_iommu = NULL;
> +
> +    intel_iommu = object_resolve_path_type("", TYPE_INTEL_IOMMU_DEVICE,
> +                                 &ambiguous);
> +    if (ambiguous)
> +        intel_iommu = NULL;
> +
> +    return (IntelIOMMUState *)intel_iommu;
> +}
> +
>  /* Do the initialization. It will also be called when reset, so pay
>   * attention when adding new initialization stuff.
>   */
> diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
> index 4914fe6..9ee84f7 100644
> --- a/include/hw/i386/intel_iommu.h
> +++ b/include/hw/i386/intel_iommu.h
> @@ -196,5 +196,7 @@ struct IntelIOMMUState {
>   * create a new one if none exists
>   */
>  VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn);
> +/* Get default IOMMU object */
> +IntelIOMMUState *vtd_iommu_get(void);
>
>  #endif
> --
> 2.4.11
>

On Thu, May 05, 2016 at 12:29:13PM +0300, David Kiarie wrote:
> On Thu, May 5, 2016 at 6:25 AM, Peter Xu <peterx@redhat.com> wrote:
> > Moves acpi_get_iommu() under VT-d to make it a public function.
> >
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >  hw/i386/acpi-build.c          |  7 +------
> >  hw/i386/intel_iommu.c         | 13 +++++++++++++
> >  include/hw/i386/intel_iommu.h |  2 ++
> >  3 files changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index 5d2d87b..b064bc2 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -2677,12 +2677,7 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
> >
> >  static bool acpi_has_iommu(void)
> >  {
> > -    bool ambiguous;
> > -    Object *intel_iommu;
> > -
> > -    intel_iommu = object_resolve_path_type("", TYPE_INTEL_IOMMU_DEVICE,
> > -                                           &ambiguous);
> > -    return intel_iommu && !ambiguous;
> > +    return !!vtd_iommu_get();
> >  }
> 
> This is not consistent with what we have in the AMD IOMMU patches but
> I guess this could be easily fixed.

Yes, I suppose there might be some conflict with corrent AMD IOMMU
patchset. The vtd_iommu_get() is further replaced by
x86_iommu_get_default() in patch 21/22. I'll possibly do a clean-up
on these overlaps in next spin. Sorry for the inconvenience.

Would you please help have a look on patches 21/22 about introducing
x86-iommu?  To see whether that would be okay for further AMD
integration.

TIA.

-- peterx