From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-4252-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 8FB4958180C6 for ; Fri, 1 Jun 2018 13:05:35 -0700 (PDT) Date: Fri, 1 Jun 2018 23:05:24 +0300 From: "Michael S. Tsirkin" Message-ID: <20180601230453-mutt-send-email-mst@kernel.org> References: <20180601012832.GA7888@vbusired-vm> <20180601184347-mutt-send-email-mst@kernel.org> <3ab81766-5de6-5508-cc3c-05cee2d44e0b@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3ab81766-5de6-5508-cc3c-05cee2d44e0b@intel.com> Subject: Re: [virtio-dev] RFC: Use of bridge devices to store pairing information... To: "Samudrala, Sridhar" Cc: Venu Busireddy , virtio-dev@lists.oasis-open.org List-ID: On Fri, Jun 01, 2018 at 10:22:59AM -0700, Samudrala, Sridhar wrote: >=20 >=20 > 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' configu= ration > > > > space some unique identifier that can be used to pair the two devic= es. > > > >=20 > > > > 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 th= is > > > > proposal and provide your thoughts. > > > >=20 > > > > 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). > > > >=20 > > > > 2. When the guest is created, the operator creates two bridge devic= es > > > > (for example, using '-device ioh3420,group_id=3D"string"'), an= d specifies > > > > a unique identifier string for both bridges. This identifier c= an be > > > > the UUID generated by 'uuidgen' command. > > > >=20 > > > > 3. QEMU places this unique identifier in the PCI configuration spac= e 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 0x3= 420). > > > >=20 > > > > 4. The operator places the passthrough device behind one of the bri= dges, > > > > and the virtio device behind the other bridge. > > > >=20 > > > > 5. Patch 4 in patch series [3] should be modified to use the unique > > > > identifier string stored in the bridges' configuration space i= nstead > > > > 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. >=20 > Yes. I also don't think we need to support pairing based solely on ID.=A0= It has be based > on MAC OR=A0 MAC+ID combination. >=20 > >=20 > > 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. >=20 > Sure. If we can use 0 ID as MAC based pairing, it may be possible to exte= nd > 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. >=20 > >=20 > > > > If it is desirable to create only one bridge instead of two (to con= serve > > > > the number of devices in the system), then the passthrough device = can be > > > > attached to that single bridge (with the identifier), and the ident= ifier > > > > for the virtio device can be stored in the virtio device's configur= ation > > > > space itself. To do that, we need to update the virtio specificatio= n, > > > > and I have sent a proposal [4] to the OASIS team to update the virt= io > > > > specification. If that proposal is accepted, then we can modify QEM= U to > > > > use the virtio device's configuration space instead of the second b= ridge > > > > to store the unique identifier. > > > I think one bridge solution is much cleaner than having to use 2 brid= ges. > > >=20 > > 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. > >=20 > >=20 > > > > Thank you for sparing the time. > > > >=20 > > > > Venu > > > >=20 > > > > [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/msg0011= 8.html > > > >=20 > > > >=20 > > > > -------------------------------------------------------------------= -- > > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.o= rg > > > >=20 > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org