On Fri, 2017-06-30 at 12:38 +0200, Peter Krempa wrote:
> Isolation groups are used to make sure any given device ends
> up on the same bus as related devices and on a different bus
> as unrelated devices.
>
> They're an abstract concept, and while working on the initial
> implementation it just happened to be convenient for me to
> have the isolation group match the IOMMU group. There's no
> specific reason that has to be the case.
Fair enough. The documentation you are adding in the linked series is
vague enough to alow this meaning too:
@@ -164,6 +164,16 @@ struct _virDomainDeviceInfo {
*/
int pciConnectFlags; /* enum virDomainPCIConnectFlags */
char *loadparm;
+
+ /* PCI devices will only be automatically placed on a PCI bus
+ * that shares the same isolation group */
+ int isolationGroup;
+
+ /* Usually, PCI buses will take on the same isolation group
+ * as the first device that is plugged into them, but in some
+ * cases we might want to prevent that from happening by
+ * locking the isolation group */
+ bool isolationGroupLocked;
};
It's vague on purpose :)
All I'm describing there is the interface from the generic
PCI address allocation code's point of view: the fact that
the QEMU driver derives isolation groups from IOMMU groups
is just an implementation detail and as such should not be
mentioned at all.
> We're never converting back and forth between the two,
which
> I agree would end up in misery at some point down the line;
> we just set the isolation group once per device and then just
> perform comparison between isolation groups from there on.
I'd suggest you create a helper to assign those then (be it from IOMMU
group or something else), so there's at least a single point that can be
referenced in the future and which will explain this reasoning.
Good idea, I'll do that!
Also adding a note that 0 means the device is not isolated would
make
sense in the structure above.
Well, devices *always* get isolated: it's just that all
guests except for pSeries only ever have a single isolation
group ;)
--
Andrea Bolognani / Red Hat / Virtualization