Re: [virtio-dev] RFC: Use of bridge devices to store pairing information...

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

On Fri, Jun 01, 2018 at 10:22:59AM -0700, Samudrala, Sridhar wrote:
> 
> 
> On 6/1/2018 8:48 AM, Michael S. Tsirkin wrote:
> > On Fri, Jun 01, 2018 at 08:26:03AM -0700, Samudrala, Sridhar wrote:
> > > On 5/31/2018 6:28 PM, 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. 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.
> > > > 
> > > > 3. QEMU places this unique identifier in the PCI configuration space of
> > > >      the bridge as Vendor-Specific capability (0x09). 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).
> > > > 
> > > > 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.
> > > This should be an alternate option that allows failover slaves to be registered
> > > based on MAC and ID.
> > I wonder whether we ever want to pair based solely on ID and not on MAC.
> > There used to be devices which randomized VF MAC on each reset but I
> > think most of them have been changed to get MAC from the PF. Not sure
> > whether any are left.
> 
> Yes. I also don't think we need to support pairing based solely on ID.  It has be based
> on MAC OR  MAC+ID combination.
> 
> > 
> > If we want the flexibility, we can use a separate feature bit for
> > matching by ID. If not we can just extend the meaning of the
> > existing one.
> 
> Sure. If we can use 0 ID as MAC based pairing, it may be possible to extend
> this without any new feature bit.

Not sure what does 0 ID mean. If it's in a capability, you just don't
add the capability.

> 
> > 
> > > > 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,
> > > > 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.
> > > I think one bridge solution is much cleaner than having to use 2 bridges.
> > > 
> > So for one bridge, we'd have a bridge with a special device/vendor ID,
> > if virtio is behind that, we use that for pairing.
> > 
> > 
> > > > 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
> > > > 
> > > > 
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > 

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org