Re: RFC: Use of bridge devices to store pairing information...

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jun 01, 2018 at 06:43:41PM +0300, Michael S. Tsirkin wrote:
> On Thu, May 31, 2018 at 08:28:32PM -0500, Venu Busireddy wrote:
> > 
> > I looked at the discussion in the threads [1] and [2], where it was
> > suggested placing the passthrough device behind one bridge, and the virtio
> > device behind another bridge, and storing in those bridges' configuration
> > space some unique identifier that can be used to pair the two devices.
> > 
> > After some discussions with Si-Wei Liu and others, we believe that the
> > following scheme may be a viable approach.
> 
> Thanks for writing this up!  I mostly agree which isn't surprising since
> I proposed this scheme originally ;)
> https://patchwork.ozlabs.org/patch/901596/#1901665
> 
> Some minor comments though:
> 
> > Please take a look at this
> > proposal and provide your thoughts.
> > 
> > 1. Enhance the QEMU CLI to include a "group_id" option to the bridge
> >    devices for Q35 as well as i440FX models. I have already made changes
> >    for the Q35 model (ioh3420 bridge).
> > 
> > 2. When the guest is created, the operator creates two bridge devices
> >    (for example, using '-device ioh3420,group_id="string"'), and specifies
> >    a unique identifier string for both bridges. This identifier can be
> >    the UUID generated by 'uuidgen' command.
> 
> I suggest we limit this to a bridge with QEMU vendor/device ID.
> 
> We have pci-bridge and pci-bridge-seat.
> 
> This could be similar: pci-bridge-group.
> Less of a chance there's a conflict.
> 
> Accordingly bridge is the group, not the id :)
> 
> > 3. QEMU places this unique identifier in the PCI configuration space of
> >    the bridge as Vendor-Specific capability (0x09).
> 
> Why not use the standard UUID capability? Accordingly name property
> uuid?
> 
> > The "Vendor" here is
> >    not to be confused with a specific organization. Instead, the vendor
> >    of the bridge is QEMU (with vendor ID 0x8086 and device ID 0x3420).
> 
> So that has a small chance of conflicting with a vendor
> specific capability used by some driver of this bridge.
> We are better off with an actual vendor/device ID IMHO.
> 
> > 4. The operator places the passthrough device behind one of the bridges,
> >    and the virtio device behind the other bridge.
> > 
> > 5. Patch 4 in patch series [3] should be modified to use the unique
> >    identifier string stored in the bridges' configuration space instead
> >    of the MAC address for pairing the devices.
> > 
> > If it is desirable to create only one bridge instead of two (to conserve
> > the  number of devices in the system), then the passthrough device can be
> > attached to that single bridge (with the identifier), and the identifier
> > for the virtio device can be stored in the virtio device's configuration
> > space itself. To do that, we need to update the virtio specification,
> 
> I think we can use the standard PCI UUID. No need to update the spec
> for this.

Thinking some more we might want to say in the spec that
PCI UUID is used for pairing so I guess yes, we do need to
update the spec after all.

> > and I have sent a proposal [4] to the OASIS team to update the virtio
> > specification. If that proposal is accepted, then we can modify QEMU to
> > use the virtio device's configuration space instead of the second bridge
> > to store the unique identifier.
> > 
> > Thank you for sparing the time.
> > 
> > Venu
> > 
> > [1] https://www.spinics.net/lists/linux-virtualization/msg33518.html
> > [2] https://www.spinics.net/lists/netdev/msg499011.html
> > [3] https://patchwork.ozlabs.org/cover/920005/
> > [4] https://lists.oasis-open.org/archives/virtio-dev/201805/msg00118.html