Re: [libvirt] [PATCH v3 25/26] qemu: Isolate hostdevs on pSeries guests
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