On Fri, Jun 30, 2017 at 12:24:33 +0200, Andrea Bolognani wrote:
> On Fri, 2017-06-30 at 10:58 +0200, Peter Krempa wrote:
> > > Or we could just, you know, do the sensible thing and
> > > store (IOMMU group + 1) instead of (IOMMU group) in
> >
> > How is that sensible? That looks as a source of bugs in the long run.
>
> 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;
};
> 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.
Also adding a note that 0 means the device is not isolated would make
sense in the structure above.
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
