Re: [libvirt] [RESEND] pci: add support for VMD domains

On 08/07/2017 03:46 PM, Jon Derrick wrote: <jonathan.derrick(a)intel.com&gt; > --- > src/util/virpci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/util/virpci.c b/src/util/virpci.c > index 2c1b758..b3afefe 100644 VIR_LOG_INIT("util.pci"); > > #define PCI_SYSFS "/sys/bus/pci/" > #define PCI_ID_LEN 10 /* "XXXX XXXX" */ > -#define PCI_ADDR_LEN 13 /* "XXXX:XX:XX.X" */ > +#define PCI_ADDR_LEN 14 /* "XXXXX:XX:XX.X" */ > > VIR_ENUM_IMPL(virPCIELinkSpeed, VIR_PCIE_LINK_SPEED_LAST, > "", "2.5", "5", "8", "16") Does just this change by itself enable new functionality? Or are other changes required? (e.g. the type "pciDomain" in the XML schema is a uint16, so any domain > 0xFFFF in the config would fail validation). Assuming that the VMD domain needs to be referenced in config somewhere in order to be useful, along with changing the type for pciDomain in docs/schemes/basictypes.rng, we would also need at least one new test case for the qemuxml2argv and qemuxml2xml tests (see the examples in the "hostdev-vfio-multidomain" and "net-hostdev-multidomain"). Also, do all versions of qemu support domains > 0xFFFF? If not, is there a feature that can be used to detect that support so we can have a capability bit for it and warn if someone tries to use such a domain when the installed version of qemu doesn't support it? (If there is no way to tell in advance, then we'll just have to live with reporting any qemu error after the fact)