Intel VMD creates secondary PCIe domain, where child devices in this
domain are aggregated behind a single end point. Linux exposes these
as special 32-bit domains, and devices in them are not individually
assignable.

This patch ignores devices in such domains as desired, and prevents
logging excessive errors, like:

  internal error: dev->name buffer overflow: 10000:00:00.0

Cc: Jonathan Derrick <jonathan.derrick@intel.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
---
 src/util/virpci.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/src/util/virpci.c b/src/util/virpci.c
index 55e4c3e49..53a6f2e51 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -1762,6 +1762,13 @@ virPCIDeviceNew(unsigned int domain,
     char *vendor = NULL;
     char *product = NULL;
 
+
+    /* Devices in a 32-bit domain are special. Currently applicable to Intel
+     * VMD PCIe, where individual devices are not individually assignable.
+     */
+    if (domain > USHRT_MAX)
+        return NULL;
+
     if (VIR_ALLOC(dev) < 0)
         return NULL;
 
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Mar 16, 2018 at 11:39:36AM -0600, Keith Busch wrote:
> Intel VMD creates secondary PCIe domain, where child devices in this
> domain are aggregated behind a single end point. Linux exposes these
> as special 32-bit domains, and devices in them are not individually
> assignable.

IIUC, your patch is addressing a problem for machines with a
specific Intel PCIe device type.

Is this  "domain >= USHRT_MAX" scenario specific to just this
Intel PCIe device type, or will such a high domain number indicate
the same semantics for devices from any vendor.

> This patch ignores devices in such domains as desired, and prevents
> logging excessive errors, like:
> 
>   internal error: dev->name buffer overflow: 10000:00:00.0
> 
> Cc: Jonathan Derrick <jonathan.derrick@intel.com>
> Signed-off-by: Keith Busch <keith.busch@intel.com>
> ---
>  src/util/virpci.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/util/virpci.c b/src/util/virpci.c
> index 55e4c3e49..53a6f2e51 100644
> --- a/src/util/virpci.c
> +++ b/src/util/virpci.c
> @@ -1762,6 +1762,13 @@ virPCIDeviceNew(unsigned int domain,
>      char *vendor = NULL;
>      char *product = NULL;
>  
> +
> +    /* Devices in a 32-bit domain are special. Currently applicable to Intel
> +     * VMD PCIe, where individual devices are not individually assignable.
> +     */
> +    if (domain > USHRT_MAX)
> +        return NULL;
> +
>      if (VIR_ALLOC(dev) < 0)
>          return NULL;
>  
> -- 
> 2.14.3
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, Mar 19, 2018 at 12:21:35PM +0000, Daniel P. Berrangé wrote:
> On Fri, Mar 16, 2018 at 11:39:36AM -0600, Keith Busch wrote:
> > Intel VMD creates secondary PCIe domain, where child devices in this
> > domain are aggregated behind a single end point. Linux exposes these
> > as special 32-bit domains, and devices in them are not individually
> > assignable.
> 
> IIUC, your patch is addressing a problem for machines with a
> specific Intel PCIe device type.
> 
> Is this  "domain >= USHRT_MAX" scenario specific to just this
> Intel PCIe device type, or will such a high domain number indicate
> the same semantics for devices from any vendor.

Yes, there is no other vendor exporting multiple PCI domains that isn't
tied to a platform sepcific 16-bit PCI _SEG.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list