[libvirt] [PATCH v3 25/26] qemu: Isolate hostdevs on pSeries guests

[Andrea Bolognani]

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