On Thu, 28 Jun 2018 09:25:32 +0100 Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Wed, Jun 27, 2018 at 07:02:36AM +0300, Michael S. Tsirkin wrote: > > On Tue, Jun 26, 2018 at 10:49:33PM -0500, Venu Busireddy wrote: > > > Add the "Vendor-Specific" capability to the Red Hat PCI bridge device > > > "pci-bridge", to contain the "Group Identifier" (UUID) that will be > > > used to pair a virtio device with the passthrough device attached to > > > that bridge. > > > > > > This capability is added to the bridge iff the "uuid" option is specified > > > for the bridge. As an aside, I don't think that will work for s390, see https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg07785.html. > > > > I think the name should be more explicit. How about "failover-group-id"? > > > > > > > > Signed-off-by: Venu Busireddy <venu.busire...@oracle.com> > > > > I'd like to also tweak the device id in this case, > > to make it easier for guests to know it's a grouping bridge. > > I tend to think this proposal is rather too narrow. The need to tell > the guest OS about the intended usage of devices is a pretty common use > case, of which setting up bonding NIC pair is just one example. FWIW, there was also discussion of making "pair those devices" a more general virtio mechanism (see https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg06339.html and around). > > OpenStack already has this problem & took the approach of providing some > structured JSON metadata to the guest that lists all devices (well NICs > and disks at least) with identifying metadata (eg PCI address, MAC addr, > disk serial and anything else relevant), and also assigns freeform string > "tags" against each. eg the host admin could specify tags "lanA" and "lanB" > for two NICs, so the guest knows which NIC to use for which purpose. This > kind of tagging could easily cover setting up bonded pairs. Or for a disk > they could tag it "oracledata" or "apachecache" to indicate what kind of > data to use on the disk, etc > > > https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html > > I'm not suggesting the impl used in OpenStack is perfect - there's a number > of pain points in it, but I think it shows the need for a general solution > to the problem of the host admin informing the guest OS about the intended > usage of devices being provided. I think freeform string tags do this > pretty well. The key problem is how to expose such tags - openstack took > approach of an out of band JSON doc exposed from its metadata service and > or cloud init config drive, because that was its only viable option. As another example, s390 has a mechanism for providing configuration information to a guest as well (see drivers/s390/char/sclp_sd.c in Linux; for a guest user space exploiter, see https://github.com/ibm-s390-tools/s390-tools/commit/7d355b0fec964ad84ecaf88eb946121d39486070 and follow-ons; the hypervisor implementation is proprietary AFAIK). > > Perhaps there is a way to expose tags at a low level though if we can > integrate with QEMU somehow ? I'd really like to see a data format that is flexible enough to cover existing needs (which can be used with different hypervisor<->guest interfaces.) We'd probably need to standardize it somehow if we want to tie in with the virtio OASIS spec. That said, for the net device standby functionality, it might be easier to just go with the VIRTIO_NET_F_STANDBY_UUID proposal while we discuss a more generic mechanism. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
