[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171207184829-mutt-send-email-mst@kernel.org>
Date: Thu, 7 Dec 2017 18:53:05 +0200
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: achiad shochat <achiad.mellanox@...il.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Hannes Frederic Sowa <hannes@...hat.com>,
Sridhar Samudrala <sridhar.samudrala@...el.com>,
netdev <netdev@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
Achiad <achiad@...lanox.com>,
Peter Waskiewicz Jr <peter.waskiewicz.jr@...el.com>,
"Singhai, Anjali" <anjali.singhai@...el.com>,
Shannon Nelson <shannon.nelson@...cle.com>,
Andy Gospodarek <gospo@...adcom.com>,
Or Gerlitz <gerlitz.or@...il.com>
Subject: Re: [RFC] virtio-net: help live migrate SR-IOV devices
On Thu, Dec 07, 2017 at 08:45:33AM -0800, Alexander Duyck wrote:
> As far as indicating that the interfaces are meant to be enslaved I
> wonder if we couldn't look at tweaking the PCI layout of the guest and
> use that to indicate that a given set of interfaces are meant to be
> bonded. For example the VFs are all meant to work as a part of a
> multi-function device. What if we were to make virtio-net function 0
> of a PCI/PCIe device, and then place any direct assigned VFs that are
> meant to be a part of the bond in functions 1-7 of the device? Then it
> isn't too far off from the model we have on the host where if the VF
> goes away we would expect to see the traffic on the PF that is usually
> occupying function 0 of a given device.
This pretty much precludes removing them with hotplug.
But as long as we are happy to limit this to pci devices,
maybe we should put them behind a pci bridge.
All devices behind a bridge would be assumed to have
the same backend.
QEMU has pci-bridge-seat which we could reuse for this -
just need to build a similar pci express bridge.
--
MST
Powered by blists - more mailing lists