On Wed, 2017-06-28 at 18:22 -0400, Laine Stump wrote:
+static int +qemuDomainFillDeviceIsolationGroupIter(virDomainDefPtr def ATTRIBUTE_UNUSED, + virDomainDeviceDefPtr dev, + virDomainDeviceInfoPtr info, + void *opaque ATTRIBUTE_UNUSED) +{ + virDomainHostdevDefPtr hostdev; + virPCIDeviceAddressPtr hostAddr; + + /* Only hostdevs... */ + if (dev->type != VIR_DOMAIN_DEVICE_HOSTDEV) + return 0; I can see one problem here - a device that is a hostdev network interface won't be properly recognized. We can solve the problem for plain <interface type='hostdev'> by just checking for that in addition to <hostdev> here.
Right, I hadn't considered that case. I'll make sure it is handled correctly.
The one that we can't deal with is <interface type='network'> where the network is a pool of VFs. We had a similar problem when trying to decide whether a device needed to be placed on a PCI or PCIe bus, but were able to punt on that one because all SRIOV devices are PCIe. In this case it's a bit more problematic though. Maybe we can do this: if a device is <interface type='network'> then we look to the network to see if it's a "hostdev network". If so, we assign it "some isolation group that won't be otherwise used" (basically *anything* that assures the device is placed on a bus by itself). It's necessary to do this because we can't know until the domain is started exactly which SRIOV VF from the pool will be used, so we can't know the actual IOMMU group in advance. And it's reasonable because each SRIOV VF is by itself in its own IOMMU group, so we won't have the exact same number as the actual iommu group, but we'll be guaranteeing that it is different from any other device (which is really all that's important in this context).
Hm, that's quite a pickle. Choosing a synthetic isolation group that is guaranteed not to clash with any host device or other VFs sounds like it might require some annoying bookkeeping. I'm not sure isolating SR-IOV VFs is really needed, though, because by virtue of being subject to their own layer of virtualization / abstraction they might being unable to take advantage of EEH and similar isolation-dependent features. David, what's your take on this?
+static int +qemuDomainSetupIsolationGroups(virDomainDefPtr def) +{ + virDomainControllerDefPtr defaultPHB; + int idx; + int ret = -1; + + /* Only pSeries guests care about isolation groups at the moment */ + if (!qemuDomainIsPSeries(def)) + return 0; I suppose this would be pointless on, e.g. Q35, since each device is on its own (isolated?) root-port anyway, right?
I don't think PCIe Root Ports provide any isolation; not of the kind we're talking about here, at least. So the concepts implemented here don't apply AFAICT. -- Andrea Bolognani / Red Hat / Virtualization