[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] RFC: Use of bridge devices to store pairing information...
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.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]