[libvirt] [RESEND] pci: add support for VMD domains
jonathan.derrick at intel.com
Wed Aug 9 16:38:11 UTC 2017
Thanks for the thoughtful reply.
On 08/08/2017 05:35 PM, Laine Stump wrote:
> On 08/07/2017 03:46 PM, Jon Derrick wrote:
>> VMD domains start at 0x10000, so expand dev->name to fit at least this > many characters. > > Signed-off-by: Jon Derrick
> <jonathan.derrick at intel.com> > --- > 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
>> --- a/src/util/virpci.c > +++ b/src/util/virpci.c > @@ -50,7 +50,7 @@
> 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).
It doesn't actually enable new functionality. The VMD product itself
doesn't currently support passthrough of child devices, so a 32-bit
domain will never be bound to a VM. This is being ensured by a kernel
patch effort, so this patch can wait until those land.
Onto other points, I see that pciDomain is uint16_t, however with my
patch I am able to return the following (which I'm not sure if it means
it still needs changing or not):
<product id='0x0953'>PCIe Data Center SSD</product>
<vendor id='0x8086'>Intel Corporation</vendor>
<link validity='cap' port='0' speed='8' width='4'/>
<link validity='sta' speed='8' width='4'/>
However the main goal of the patch was to squash the following warning
and potential issue:
Feb 23 21:16:24 localhost journal: internal error: dev->name buffer
If you would prefer, I can resend the patch with the above error
pointing out that the patch fixes this issue alone.
> 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").
I'd be happy to look into this when, if ever, we do actually support
passthrough of VMD child devices within the kernel.
> 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)
At a first glance, QEMU somewhat supports it. Several domain references
use int, but others use uint16_t. I can take a look at cleaning this up,
but as stated above, VMD child devices won't actually be passed-through
in the foreseeable future. In the past I have done QEMU passthrough
tests with just the VMD endpoint (which resides on a 16-bit domain). The
guest is then responsible for child devices. This mode of operation is
the only one we officially support.
More information about the libvir-list