From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-4246-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [66.179.20.138]) by lists.oasis-open.org (Postfix) with ESMTP id 7ED3B5818F0F for ; Fri, 1 Jun 2018 08:43:43 -0700 (PDT) Date: Fri, 1 Jun 2018 18:43:41 +0300 From: "Michael S. Tsirkin" Message-ID: <20180601182834-mutt-send-email-mst@kernel.org> References: <20180601012832.GA7888@vbusired-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180601012832.GA7888@vbusired-vm> Subject: [virtio-dev] Re: RFC: Use of bridge devices to store pairing information... To: Venu Busireddy Cc: virtio-dev@lists.oasis-open.org List-ID: 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. > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org