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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
