From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net Date: Tue, 12 Jun 2018 14:34:56 +0300 Message-ID: <20180612142557-mutt-send-email-mst@kernel.org> References: <1525734594-11134-1-git-send-email-sridhar.samudrala@intel.com> <20180611202207-mutt-send-email-mst@kernel.org> <20180612051432-mutt-send-email-mst@kernel.org> <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: alexander.h.duyck@intel.com, virtio-dev@lists.oasis-open.org, aaron.f.brown@intel.com, jiri@resnulli.us, kubakici@wp.pl, netdev@vger.kernel.org, qemu-devel@nongnu.org, loseweigh@gmail.com, virtualization@lists.linux-foundation.org To: "Samudrala, Sridhar" Return-path: Content-Disposition: inline In-Reply-To: <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org T24gTW9uLCBKdW4gMTEsIDIwMTggYXQgMTA6MDI6NDVQTSAtMDcwMCwgU2FtdWRyYWxhLCBTcmlk aGFyIHdyb3RlOgo+IE9uIDYvMTEvMjAxOCA3OjE3IFBNLCBNaWNoYWVsIFMuIFRzaXJraW4gd3Jv dGU6Cj4gPiBPbiBUdWUsIEp1biAxMiwgMjAxOCBhdCAwOTo1NDo0NEFNICswODAwLCBKYXNvbiBX YW5nIHdyb3RlOgo+ID4gPiAKPiA+ID4gT24gMjAxOOW5tDA25pyIMTLml6UgMDE6MjYsIE1pY2hh ZWwgUy4gVHNpcmtpbiB3cm90ZToKPiA+ID4gPiBPbiBNb24sIE1heSAwNywgMjAxOCBhdCAwNDow OTo1NFBNIC0wNzAwLCBTcmlkaGFyIFNhbXVkcmFsYSB3cm90ZToKPiA+ID4gPiA+IFRoaXMgZmVh dHVyZSBiaXQgY2FuIGJlIHVzZWQgYnkgaHlwZXJ2aXNvciB0byBpbmRpY2F0ZSB2aXJ0aW9fbmV0 IGRldmljZSB0bwo+ID4gPiA+ID4gYWN0IGFzIGEgc3RhbmRieSBmb3IgYW5vdGhlciBkZXZpY2Ug d2l0aCB0aGUgc2FtZSBNQUMgYWRkcmVzcy4KPiA+ID4gPiA+IAo+ID4gPiA+ID4gSSB0ZXN0ZWQg dGhpcyB3aXRoIGEgc21hbGwgY2hhbmdlIHRvIHRoZSBwYXRjaCB0byBtYXJrIHRoZSBTVEFOREJZ IGZlYXR1cmUgJ3RydWUnCj4gPiA+ID4gPiBieSBkZWZhdWx0IGFzIGkgYW0gdXNpbmcgbGlidmly dCB0byBzdGFydCB0aGUgVk1zLgo+ID4gPiA+ID4gSXMgdGhlcmUgYSB3YXkgdG8gcGFzcyB0aGUg bmV3bHkgYWRkZWQgZmVhdHVyZSBiaXQgJ3N0YW5kYnknIHRvIHFlbXUgdmlhIGxpYnZpcnQKPiA+ ID4gPiA+IFhNTCBmaWxlPwo+ID4gPiA+ID4gCj4gPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBTcmlk aGFyIFNhbXVkcmFsYSA8c3JpZGhhci5zYW11ZHJhbGFAaW50ZWwuY29tPgo+ID4gPiA+IFNvIEkg ZG8gbm90IHRoaW5rIHdlIGNhbiBjb21taXQgdG8gdGhpcyBpbnRlcmZhY2U6IHdlCj4gPiA+ID4g cmVhbGx5IG5lZWQgdG8gY29udHJvbCB2aXNpYmlsaXR5IG9mIHRoZSBwcmltYXJ5IGRldmljZS4K PiA+ID4gVGhlIHByb2JsZW0gaXMgbGVnYWN5IGd1ZXN0IHdvbid0IHVzZSBwcmltYXJ5IGRldmlj ZSBhdCBhbGwgaWYgd2UgZG8gdGhpcy4KPiA+IEFuZCB0aGF0J3MgYnkgZGVzaWduIC0gSSB0aGlu ayBpdCdzIHRoZSBvbmx5IHdheSB0byBlbnN1cmUgdGhlCj4gPiBsZWdhY3kgZ3Vlc3QgaXNuJ3Qg Y29uZnVzZWQuCj4gCj4gWWVzLiBJIHRoaW5rIHNvLiBCdXQgaSBhbSBub3Qgc3VyZSBpZiBRZW11 IGlzIHRoZSByaWdodCBwbGFjZSB0byBjb250cm9sIHRoZSB2aXNpYmlsaXR5Cj4gb2YgdGhlIHBy aW1hcnkgZGV2aWNlLiBUaGUgcHJpbWFyeSBkZXZpY2UgbWF5IG5vdCBiZSBzcGVjaWZpZWQgYXMg YW4gYXJndW1lbnQgdG8gUWVtdS4gSXQKPiBtYXkgYmUgcGx1Z2dlZCBpbiBsYXRlci4KPiBUaGUg Y2xvdWQgc2VydmljZSBwcm92aWRlciBpcyBwcm92aWRpbmcgYSBmZWF0dXJlIHRoYXQgZW5hYmxl cyBsb3cgbGF0ZW5jeSBkYXRhcGF0aCBhbmQgbGl2ZQo+IG1pZ3JhdGlvbiBjYXBhYmlsaXR5Lgo+ IEEgdGVuYW50IGNhbiB1c2UgdGhpcyBmZWF0dXJlIG9ubHkgaWYgaGUgaXMgcnVubmluZyBhIFZN IHRoYXQgaGFzIHZpcnRpby1uZXQgd2l0aCBmYWlsb3ZlciBzdXBwb3J0LgoKV2VsbCBsaXZlIG1p Z3JhdGlvbiBpcyB0aGVyZSBhbHJlYWR5LiBUaGUgbmV3IGZlYXR1cmUgaXMgbG93IGxhdGVuY3kK ZGF0YSBwYXRoLgoKQW5kIGl0J3MgdGhlIGd1ZXN0IHRoYXQgbmVlZHMgZmFpbG92ZXIgc3VwcG9y dCBub3QgdGhlIFZNLgoKCj4gSSB0aGluayBRZW11IHNob3VsZCBjaGVjayBpZiBndWVzdCB2aXJ0 aW8tbmV0IHN1cHBvcnRzIHRoaXMgZmVhdHVyZSBhbmQgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IK PiBhbiB1cHBlciBsYXllciBpbmRpY2F0aW5nIGlmIHRoZSBTVEFOREJZIGZlYXR1cmUgaXMgc3Vj Y2Vzc2Z1bGx5IG5lZ290aWF0ZWQgb3Igbm90Lgo+IFRoZSB1cHBlciBsYXllciBjYW4gdGhlbiBk ZWNpZGUgaWYgaXQgc2hvdWxkIGhvdCBwbHVnIGEgVkYgd2l0aCB0aGUgc2FtZSBNQUMgYW5kIG1h bmFnZSB0aGUgMiBsaW5rcy4KPiBJZiBWRiBpcyBzdWNjZXNzZnVsbHkgaG90IHBsdWdnZWQsIHZp cnRpby1uZXQgbGluayBzaG91bGQgYmUgZGlzYWJsZWQuCgpEaWQgeW91IGV2ZW4gdGFsayB0byB1 cHBlciBsYXllciBtYW5hZ2VtZW50IGFib3V0IGl0PwpKdXN0IGxpc3QgdGhlIHN0ZXBzIHRoZXkg bmVlZCB0byBkbyBhbmQgeW91IHdpbGwgc2VlCnRoYXQncyBhIGxvdCBvZiBtYWNoaW5lcnkgdG8g bWFuYWdlIGJ5IHRoZSB1cHBlciBsYXllci4KCldoYXQgZG8gd2UgZ2FpbiBpbiBmbGV4aWJpbGl0 eT8gQXMgZmFyIGFzIEkgY2FuIHNlZSB0aGUKb25seSBnYWluIGlzIHNvbWUgcmVzb3VyY2VzIHNh dmVkIGZvciBsZWdhY3kgVk1zLgoKVGhhdCdzIG5vdCBhIGxvdCBhcyB0ZW5hbnQgb2YgdGhlIHVw cGVyIGxheWVyIHByb2JhYmx5IGFscmVhZHkgaGFzCmF0IGxlYXN0IGEgaHVuY2ggdGhhdCBpdCdz IGEgbmV3IGd1ZXN0IG90aGVyd2lzZQp3aHkgYm90aGVyIHNwZWNpZnlpbmcgdGhlIGZlYXR1cmUg YXQgYWxsIC0geW91CnNhdmUgZXZlbiBtb3JlIHJlc291cmNlcyB3aXRob3V0IGl0LgoKCgoKPiAK PiA+IAo+ID4gPiBIb3cgYWJvdXQgY29udHJvbCB0aGUgdmlzaWJpbGl0eSBvZiBzdGFuZGJ5IGRl dmljZT8KPiA+ID4gCj4gPiA+IFRoYW5rcwo+ID4gc3RhbmR5IHRoZSBhbHdheXMgdGhlcmUgdG8g Z3VhcmFudGVlIG5vIGRvd250aW1lLgo+ID4gCj4gPiA+ID4gSG93ZXZlciBqdXN0IGZvciB0ZXN0 aW5nIHB1cnBvc2VzLCB3ZSBjb3VsZCBhZGQgYSBub24tc3RhYmxlCj4gPiA+ID4gaW50ZXJmYWNl ICJ4LXN0YW5kYnkiIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCBhcyBhbnkKPiA+ID4gPiB4 LSBwcmVmaXggaXQncyB1bnN0YWJsZSBhbmQgd2lsbCBiZSBjaGFuZ2VkIGRvd24gdGhlIHJvYWQs Cj4gPiA+ID4gbGlrZWx5IGluIHRoZSBuZXh0IHJlbGVhc2UuCj4gPiA+ID4gCj4gPiA+ID4gCj4g PiA+ID4gPiAtLS0KPiA+ID4gPiA+ICAgIGh3L25ldC92aXJ0aW8tbmV0LmMgICAgICAgICAgICAg ICAgICAgICAgICAgfCAyICsrCj4gPiA+ID4gPiAgICBpbmNsdWRlL3N0YW5kYXJkLWhlYWRlcnMv bGludXgvdmlydGlvX25ldC5oIHwgMyArKysKPiA+ID4gPiA+ICAgIDIgZmlsZXMgY2hhbmdlZCwg NSBpbnNlcnRpb25zKCspCj4gPiA+ID4gPiAKPiA+ID4gPiA+IGRpZmYgLS1naXQgYS9ody9uZXQv dmlydGlvLW5ldC5jIGIvaHcvbmV0L3ZpcnRpby1uZXQuYwo+ID4gPiA+ID4gaW5kZXggOTA1MDJm Y2E3Yy4uMzhiMzE0MDY3MCAxMDA2NDQKPiA+ID4gPiA+IC0tLSBhL2h3L25ldC92aXJ0aW8tbmV0 LmMKPiA+ID4gPiA+ICsrKyBiL2h3L25ldC92aXJ0aW8tbmV0LmMKPiA+ID4gPiA+IEBAIC0yMTk4 LDYgKzIxOTgsOCBAQCBzdGF0aWMgUHJvcGVydHkgdmlydGlvX25ldF9wcm9wZXJ0aWVzW10gPSB7 Cj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICB0cnVlKSwKPiA+ID4gPiA+ICAgICAg ICBERUZJTkVfUFJPUF9JTlQzMigic3BlZWQiLCBWaXJ0SU9OZXQsIG5ldF9jb25mLnNwZWVkLCBT UEVFRF9VTktOT1dOKSwKPiA+ID4gPiA+ICAgICAgICBERUZJTkVfUFJPUF9TVFJJTkcoImR1cGxl eCIsIFZpcnRJT05ldCwgbmV0X2NvbmYuZHVwbGV4X3N0ciksCj4gPiA+ID4gPiArICAgIERFRklO RV9QUk9QX0JJVDY0KCJzdGFuZGJ5IiwgVmlydElPTmV0LCBob3N0X2ZlYXR1cmVzLCBWSVJUSU9f TkVUX0ZfU1RBTkRCWSwKPiA+ID4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgZmFsc2UpLAo+ ID4gPiA+ID4gICAgICAgIERFRklORV9QUk9QX0VORF9PRl9MSVNUKCksCj4gPiA+ID4gPiAgICB9 Owo+ID4gPiA+ID4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvc3RhbmRhcmQtaGVhZGVycy9saW51eC92 aXJ0aW9fbmV0LmggYi9pbmNsdWRlL3N0YW5kYXJkLWhlYWRlcnMvbGludXgvdmlydGlvX25ldC5o Cj4gPiA+ID4gPiBpbmRleCBlOWYyNTVlYTNmLi4wMWVjMDk2ODRjIDEwMDY0NAo+ID4gPiA+ID4g LS0tIGEvaW5jbHVkZS9zdGFuZGFyZC1oZWFkZXJzL2xpbnV4L3ZpcnRpb19uZXQuaAo+ID4gPiA+ ID4gKysrIGIvaW5jbHVkZS9zdGFuZGFyZC1oZWFkZXJzL2xpbnV4L3ZpcnRpb19uZXQuaAo+ID4g PiA+ID4gQEAgLTU3LDYgKzU3LDkgQEAKPiA+ID4gPiA+ICAgIAkJCQkJICogU3RlZXJpbmcgKi8K PiA+ID4gPiA+ICAgICNkZWZpbmUgVklSVElPX05FVF9GX0NUUkxfTUFDX0FERFIgMjMJLyogU2V0 IE1BQyBhZGRyZXNzICovCj4gPiA+ID4gPiArI2RlZmluZSBWSVJUSU9fTkVUX0ZfU1RBTkRCWSAg ICAgIDYyICAgIC8qIEFjdCBhcyBzdGFuZGJ5IGZvciBhbm90aGVyIGRldmljZQo+ID4gPiA+ID4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiB3aXRoIHRoZSBzYW1l IE1BQy4KPiA+ID4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICovCj4gPiA+ID4gPiAgICAjZGVmaW5lIFZJUlRJT19ORVRfRl9TUEVFRF9EVVBMRVggNjMJLyog RGV2aWNlIHNldCBsaW5rc3BlZWQgYW5kIGR1cGxleCAqLwo+ID4gPiA+ID4gICAgI2lmbmRlZiBW SVJUSU9fTkVUX05PX0xFR0FDWQo+ID4gPiA+ID4gLS0gCj4gPiA+ID4gPiAyLjE0LjMKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVmlydHVhbGl6YXRpb24g bWFpbGluZyBsaXN0ClZpcnR1YWxpemF0aW9uQGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0 dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZpcnR1YWxp emF0aW9u From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fShZo-0002BO-7P for qemu-devel@nongnu.org; Tue, 12 Jun 2018 07:35:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fShZk-0001vj-In for qemu-devel@nongnu.org; Tue, 12 Jun 2018 07:35:03 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:38996 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fShZk-0001vQ-Bi for qemu-devel@nongnu.org; Tue, 12 Jun 2018 07:35:00 -0400 Date: Tue, 12 Jun 2018 14:34:56 +0300 From: "Michael S. Tsirkin" Message-ID: <20180612142557-mutt-send-email-mst@kernel.org> References: <1525734594-11134-1-git-send-email-sridhar.samudrala@intel.com> <20180611202207-mutt-send-email-mst@kernel.org> <20180612051432-mutt-send-email-mst@kernel.org> <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Samudrala, Sridhar" Cc: Jason Wang , alexander.h.duyck@intel.com, virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, jiri@resnulli.us, kubakici@wp.pl, netdev@vger.kernel.org, jesse.brandeburg@intel.com, virtualization@lists.linux-foundation.org, loseweigh@gmail.com, aaron.f.brown@intel.com On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote: > On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote: > > On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote: > > >=20 > > > On 2018=E5=B9=B406=E6=9C=8812=E6=97=A5 01:26, Michael S. Tsirkin wr= ote: > > > > On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote= : > > > > > This feature bit can be used by hypervisor to indicate virtio_n= et device to > > > > > act as a standby for another device with the same MAC address. > > > > >=20 > > > > > I tested this with a small change to the patch to mark the STAN= DBY feature 'true' > > > > > by default as i am using libvirt to start the VMs. > > > > > Is there a way to pass the newly added feature bit 'standby' to= qemu via libvirt > > > > > XML file? > > > > >=20 > > > > > Signed-off-by: Sridhar Samudrala > > > > So I do not think we can commit to this interface: we > > > > really need to control visibility of the primary device. > > > The problem is legacy guest won't use primary device at all if we d= o this. > > And that's by design - I think it's the only way to ensure the > > legacy guest isn't confused. >=20 > Yes. I think so. But i am not sure if Qemu is the right place to contro= l the visibility > of the primary device. The primary device may not be specified as an ar= gument to Qemu. It > may be plugged in later. > The cloud service provider is providing a feature that enables low late= ncy datapath and live > migration capability. > A tenant can use this feature only if he is running a VM that has virti= o-net with failover support. Well live migration is there already. The new feature is low latency data path. And it's the guest that needs failover support not the VM. > I think Qemu should check if guest virtio-net supports this feature and= provide a mechanism for > an upper layer indicating if the STANDBY feature is successfully negoti= ated or not. > The upper layer can then decide if it should hot plug a VF with the sam= e MAC and manage the 2 links. > If VF is successfully hot plugged, virtio-net link should be disabled. Did you even talk to upper layer management about it? Just list the steps they need to do and you will see that's a lot of machinery to manage by the upper layer. What do we gain in flexibility? As far as I can see the only gain is some resources saved for legacy VMs. That's not a lot as tenant of the upper layer probably already has at least a hunch that it's a new guest otherwise why bother specifying the feature at all - you save even more resources without it. >=20 > >=20 > > > How about control the visibility of standby device? > > >=20 > > > Thanks > > standy the always there to guarantee no downtime. > >=20 > > > > However just for testing purposes, we could add a non-stable > > > > interface "x-standby" with the understanding that as any > > > > x- prefix it's unstable and will be changed down the road, > > > > likely in the next release. > > > >=20 > > > >=20 > > > > > --- > > > > > hw/net/virtio-net.c | 2 ++ > > > > > include/standard-headers/linux/virtio_net.h | 3 +++ > > > > > 2 files changed, 5 insertions(+) > > > > >=20 > > > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c > > > > > index 90502fca7c..38b3140670 100644 > > > > > --- a/hw/net/virtio-net.c > > > > > +++ b/hw/net/virtio-net.c > > > > > @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] =3D= { > > > > > true), > > > > > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SP= EED_UNKNOWN), > > > > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_= str), > > > > > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIR= TIO_NET_F_STANDBY, > > > > > + false), > > > > > DEFINE_PROP_END_OF_LIST(), > > > > > }; > > > > > diff --git a/include/standard-headers/linux/virtio_net.h b/incl= ude/standard-headers/linux/virtio_net.h > > > > > index e9f255ea3f..01ec09684c 100644 > > > > > --- a/include/standard-headers/linux/virtio_net.h > > > > > +++ b/include/standard-headers/linux/virtio_net.h > > > > > @@ -57,6 +57,9 @@ > > > > > * Steering */ > > > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > > > > > +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for = another device > > > > > + * with the same MAC. > > > > > + */ > > > > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed= and duplex */ > > > > > #ifndef VIRTIO_NET_NO_LEGACY > > > > > --=20 > > > > > 2.14.3 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-4352-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 ECE5258191A7 for ; Tue, 12 Jun 2018 04:35:11 -0700 (PDT) Date: Tue, 12 Jun 2018 14:34:56 +0300 From: "Michael S. Tsirkin" Message-ID: <20180612142557-mutt-send-email-mst@kernel.org> References: <1525734594-11134-1-git-send-email-sridhar.samudrala@intel.com> <20180611202207-mutt-send-email-mst@kernel.org> <20180612051432-mutt-send-email-mst@kernel.org> <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com> Subject: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net To: "Samudrala, Sridhar" Cc: Jason Wang , alexander.h.duyck@intel.com, virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, jiri@resnulli.us, kubakici@wp.pl, netdev@vger.kernel.org, jesse.brandeburg@intel.com, virtualization@lists.linux-foundation.org, loseweigh@gmail.com, aaron.f.brown@intel.com List-ID: On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote: > On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote: > > On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote: > > > > > > On 2018年06月12日 01:26, Michael S. Tsirkin wrote: > > > > On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote: > > > > > This feature bit can be used by hypervisor to indicate virtio_net device to > > > > > act as a standby for another device with the same MAC address. > > > > > > > > > > I tested this with a small change to the patch to mark the STANDBY feature 'true' > > > > > by default as i am using libvirt to start the VMs. > > > > > Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt > > > > > XML file? > > > > > > > > > > Signed-off-by: Sridhar Samudrala > > > > So I do not think we can commit to this interface: we > > > > really need to control visibility of the primary device. > > > The problem is legacy guest won't use primary device at all if we do this. > > And that's by design - I think it's the only way to ensure the > > legacy guest isn't confused. > > Yes. I think so. But i am not sure if Qemu is the right place to control the visibility > of the primary device. The primary device may not be specified as an argument to Qemu. It > may be plugged in later. > The cloud service provider is providing a feature that enables low latency datapath and live > migration capability. > A tenant can use this feature only if he is running a VM that has virtio-net with failover support. Well live migration is there already. The new feature is low latency data path. And it's the guest that needs failover support not the VM. > I think Qemu should check if guest virtio-net supports this feature and provide a mechanism for > an upper layer indicating if the STANDBY feature is successfully negotiated or not. > The upper layer can then decide if it should hot plug a VF with the same MAC and manage the 2 links. > If VF is successfully hot plugged, virtio-net link should be disabled. Did you even talk to upper layer management about it? Just list the steps they need to do and you will see that's a lot of machinery to manage by the upper layer. What do we gain in flexibility? As far as I can see the only gain is some resources saved for legacy VMs. That's not a lot as tenant of the upper layer probably already has at least a hunch that it's a new guest otherwise why bother specifying the feature at all - you save even more resources without it. > > > > > > How about control the visibility of standby device? > > > > > > Thanks > > standy the always there to guarantee no downtime. > > > > > > However just for testing purposes, we could add a non-stable > > > > interface "x-standby" with the understanding that as any > > > > x- prefix it's unstable and will be changed down the road, > > > > likely in the next release. > > > > > > > > > > > > > --- > > > > > hw/net/virtio-net.c | 2 ++ > > > > > include/standard-headers/linux/virtio_net.h | 3 +++ > > > > > 2 files changed, 5 insertions(+) > > > > > > > > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c > > > > > index 90502fca7c..38b3140670 100644 > > > > > --- a/hw/net/virtio-net.c > > > > > +++ b/hw/net/virtio-net.c > > > > > @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = { > > > > > true), > > > > > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), > > > > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), > > > > > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, > > > > > + false), > > > > > DEFINE_PROP_END_OF_LIST(), > > > > > }; > > > > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h > > > > > index e9f255ea3f..01ec09684c 100644 > > > > > --- a/include/standard-headers/linux/virtio_net.h > > > > > +++ b/include/standard-headers/linux/virtio_net.h > > > > > @@ -57,6 +57,9 @@ > > > > > * Steering */ > > > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > > > > > +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device > > > > > + * with the same MAC. > > > > > + */ > > > > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */ > > > > > #ifndef VIRTIO_NET_NO_LEGACY > > > > > -- > > > > > 2.14.3 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org