From: Venu Busireddy <venu.busireddy@oracle.com>
To: virtio-dev@lists.oasis-open.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Subject: [virtio-dev] RFC: Use of bridge devices to store pairing information...
Date: Thu, 31 May 2018 20:28:32 -0500 [thread overview]
Message-ID: <20180601012832.GA7888@vbusired-vm> (raw)
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.
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.
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
next reply other threads:[~2018-06-01 1:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 1:28 Venu Busireddy [this message]
2018-06-01 15:26 ` [virtio-dev] RFC: Use of bridge devices to store pairing information Samudrala, Sridhar
2018-06-01 15:48 ` Michael S. Tsirkin
2018-06-01 17:22 ` Samudrala, Sridhar
2018-06-01 20:05 ` Michael S. Tsirkin
2018-06-01 20:31 ` Siwei Liu
2018-06-01 20:37 ` Venu Busireddy
2018-06-01 21:04 ` Michael S. Tsirkin
2018-06-01 21:01 ` Michael S. Tsirkin
2018-06-01 15:43 ` [virtio-dev] " Michael S. Tsirkin
2018-06-01 15:45 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180601012832.GA7888@vbusired-vm \
--to=venu.busireddy@oracle.com \
--cc=mst@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.