diff mbox

[v2,08/30] xen/x86: do the PCI scan unconditionally

Message ID 1474991845-27962-9-git-send-email-roger.pau@citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

Roger Pau Monne Sept. 27, 2016, 3:57 p.m. UTC
Instead of being tied to the presence of an IOMMU

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Feng Wu <feng.wu@intel.com>
---
 xen/arch/x86/setup.c                        | 2 ++
 xen/drivers/passthrough/amd/pci_amd_iommu.c | 3 ++-
 xen/drivers/passthrough/vtd/iommu.c         | 2 --
 3 files changed, 4 insertions(+), 3 deletions(-)

Comments

Jan Beulich Sept. 29, 2016, 1:55 p.m. UTC | #1
>>> On 27.09.16 at 17:57, <roger.pau@citrix.com> wrote:
> Instead of being tied to the presence of an IOMMU

At the very least I'd expect the "why" aspect to get mentioned
here.

> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -219,7 +219,8 @@ int __init amd_iov_detect(void)
>  
>      if ( !amd_iommu_perdev_intremap )
>          printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is not recommended (see XSA-36)!\n");
> -    return scan_pci_devices();
> +
> +    return 0;
>  }

Not how an error return from the function at least here does not
get ignored, leading to the IOMMU not getting enabled. This behavior
should be preserved, and I think it actually should extend to VT-d.
Furthermore iiuc you make PVHv2 Dom0 setup depend on this
succeeding, which may then require further propagation of the
success status here (or maybe, just like PVHv1, you require a
functional IOMMU, in which case failing IOMMU setup would be
sufficient).

Jan
Roger Pau Monne Sept. 29, 2016, 3:11 p.m. UTC | #2
On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, <roger.pau@citrix.com> wrote:
> > Instead of being tied to the presence of an IOMMU
> 
> At the very least I'd expect the "why" aspect to get mentioned
> here.

TBH, it seems simpler to have it there rather than conditional to the 
presence of an IOMMU. Also, I think scan_pci_devices failing should be 
fatal. Would you be OK with me adding a panic if the scan fails?

> > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > @@ -219,7 +219,8 @@ int __init amd_iov_detect(void)
> >  
> >      if ( !amd_iommu_perdev_intremap )
> >          printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is not recommended (see XSA-36)!\n");
> > -    return scan_pci_devices();
> > +
> > +    return 0;
> >  }
> 
> Not how an error return from the function at least here does not
> get ignored, leading to the IOMMU not getting enabled. This behavior
> should be preserved, and I think it actually should extend to VT-d.
> Furthermore iiuc you make PVHv2 Dom0 setup depend on this
> succeeding, which may then require further propagation of the
> success status here (or maybe, just like PVHv1, you require a
> functional IOMMU, in which case failing IOMMU setup would be
> sufficient).

Yes, PVHv2, just like PVHv1 requires a functional IOMMU, see 
check_hwdom_reqs in passthrough/iommu.c (if the hardware domain is using a 
translated paging mode an IOMMU is required).

Roger.
Jan Beulich Sept. 29, 2016, 4:14 p.m. UTC | #3
>>> On 29.09.16 at 17:11, <roger.pau@citrix.com> wrote:
> On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, <roger.pau@citrix.com> wrote:
>> > Instead of being tied to the presence of an IOMMU
>> 
>> At the very least I'd expect the "why" aspect to get mentioned
>> here.
> 
> TBH, it seems simpler to have it there rather than conditional to the 
> presence of an IOMMU. Also, I think scan_pci_devices failing should be 
> fatal. Would you be OK with me adding a panic if the scan fails?

Hmm, no, not really. We can do without knowing of any PCI
devices right now, so I don't see why this should become a
panic. The more that we don't do a complete scan anyway, so
we know information is going to be at best partial until Dom0
gives us a complete picture.

Jan
diff mbox

Patch

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ae897a..1d27a6f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1443,6 +1443,8 @@  void __init noreturn __start_xen(unsigned long mbi_p)
 
     early_msi_init();
 
+    scan_pci_devices();
+
     iommu_setup();    /* setup iommu if available */
 
     smp_prepare_cpus(max_cpus);
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 94a25a4..d12575d 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -219,7 +219,8 @@  int __init amd_iov_detect(void)
 
     if ( !amd_iommu_perdev_intremap )
         printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is not recommended (see XSA-36)!\n");
-    return scan_pci_devices();
+
+    return 0;
 }
 
 static int allocate_domain_resources(struct domain_iommu *hd)
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 48f120b..919993e 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2299,8 +2299,6 @@  int __init intel_vtd_setup(void)
     P(iommu_hap_pt_share, "Shared EPT tables");
 #undef P
 
-    scan_pci_devices();
-
     ret = init_vtd_hw();
     if ( ret )
         goto error;