diff for duplicates of <1527697588.16245.136.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index c8d8573..ad4ba2d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,25 +1,31 @@ -T24gV2VkLCAyMDE4LTA1LTMwIGF0IDE5OjIyICswMzAwLCBNaWNoYWVsIFMuIFRzaXJraW4gd3Jv -dGU6DQo+IE9uIFdlZCwgTWF5IDMwLCAyMDE4IGF0IDA5OjEwOjU3QU0gLTA3MDAsIEFsZXhhbmRl -ciBEdXljayB3cm90ZToNCj4gPiBPbiBXZWQsIE1heSAzMCwgMjAxOCBhdCAxOjU1IEFNLCBUaXdl -aSBCaWUgPHRpd2VpLmJpZUBpbnRlbC5jb20+IHdyb3RlOg0KPiA+ID4gVGhlcmUgaXMgYSBuZXcg -ZmVhdHVyZSBiaXQgYWxsb2NhdGVkIGluIHZpcnRpbyBzcGVjIHRvDQo+ID4gPiBzdXBwb3J0IFNS -LUlPViAoU2luZ2xlIFJvb3QgSS9PIFZpcnR1YWxpemF0aW9uKToNCj4gPiA+IA0KPiA+ID4gaHR0 -cHM6Ly9naXRodWIuY29tL29hc2lzLXRjcy92aXJ0aW8tc3BlYy9pc3N1ZXMvMTENCj4gPiA+IA0K -PiA+ID4gVGhpcyBwYXRjaCBlbmFibGVzIHRoZSBzdXBwb3J0IGZvciB0aGlzIGZlYXR1cmUgYml0 -IGluDQo+ID4gPiB2aXJ0aW8gZHJpdmVyLg0KPiA+ID4gDQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBU -aXdlaSBCaWUgPHRpd2VpLmJpZUBpbnRlbC5jb20+DQo+ID4gDQo+ID4gU28gZnJvbSBhIHF1aWNr -IGdsYW5jZSBpdCBsb29rcyBsaWtlIHdlIGFyZSBsZWF2aW5nIFNSLUlPViBlbmFibGVkIGlmDQo+ -ID4gdGhlIGRyaXZlciBpcyByZW1vdmVkLiBEbyB3ZSB3YW50IHRvIGhhdmUgdGhhdCBiZWhhdmlv -ciBvciBzaG91bGQgd2UNCj4gPiBiZSBhZGRpbmcgdGhlIGNvZGUgdG8gZGlzYWJsZSBTUi1JT1Yg -YW5kIGZyZWUgdGhlIFZGcyBvbiBkcml2ZXINCj4gPiByZW1vdmFsPw0KPiANCj4gQ291bGQgcGNp -IGNvcmUgaGFuZGxlIGl0IGZvciB1cyBzb21laG93Pw0KDQpNYXliZSwgYnV0IGl0IHdvdWxkIHJl -cXVpcmUgY2hhbmdlcyB0byB0aGUgcGNpIGNvcmUgdG8gZG8gaXQuDQoNClRoZSBwcm9ibGVtIGlz -IHNvbWUgZHJpdmVycyB3YW50IHRvIGxlYXZlIHRoZSBWRnMgdGhlcmUgc2luY2UgdGhlIFBGDQpk -b2Vzbid0IHJlYWxseSBkbyBhbnl0aGluZywgb3IgdGhleSBoYXZlIHRoZSBvcHRpb24gb2YgZXNz -ZW50aWFsbHkNCnB1dHRpbmcgdGhlIFZGcyBpbnRvIGEgc3RhbmRieSBzdGF0ZSB3aGVuIHRoZSBQ -RiBpcyBnb25lLg0KDQpNeSBtYWluIGNvbmNlcm4gaXMgZG8gd2UgY2FyZSBpZiBWRnMgYXJlIGFs -bG9jYXRlZCBhbmQgdGhlbiBzb21lYm9keQ0KcmVtb3ZlcyB0aGUgZHJpdmVyIGFuZCBiaW5kcyBh -IGRpZmZlcmVudCBkcml2ZXIgdG8gdGhlIGludGVyZmFjZT8gSWYNCm5vdCB0aGVuIHRoaXMgY29k -ZSBhbmQgYmUgbGVmdCBhcyBpcywgYnV0IEkganVzdCB3YW50ZWQgdG8gYmUgY2VydGFpbg0Kc2lu -Y2UgSSBrbm93IHRoaXMgaXNuJ3QganVzdCBlbmFibGluZyBTUi1JT1Ygd2UgYXJlIGhhdmluZyB0 -byBkbyBhDQpudW1iZXIgb2Ygb3RoZXIgY2hlY2tzIGFnYWluc3QgdGhlIHZpcnRpbyBkZXZpY2Uu +On Wed, 2018-05-30 at 19:22 +0300, Michael S. Tsirkin wrote: +> On Wed, May 30, 2018 at 09:10:57AM -0700, Alexander Duyck wrote: +> > On Wed, May 30, 2018 at 1:55 AM, Tiwei Bie <tiwei.bie@intel.com> wrote: +> > > There is a new feature bit allocated in virtio spec to +> > > support SR-IOV (Single Root I/O Virtualization): +> > > +> > > https://github.com/oasis-tcs/virtio-spec/issues/11 +> > > +> > > This patch enables the support for this feature bit in +> > > virtio driver. +> > > +> > > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com> +> > +> > So from a quick glance it looks like we are leaving SR-IOV enabled if +> > the driver is removed. Do we want to have that behavior or should we +> > be adding the code to disable SR-IOV and free the VFs on driver +> > removal? +> +> Could pci core handle it for us somehow? + +Maybe, but it would require changes to the pci core to do it. + +The problem is some drivers want to leave the VFs there since the PF +doesn't really do anything, or they have the option of essentially +putting the VFs into a standby state when the PF is gone. + +My main concern is do we care if VFs are allocated and then somebody +removes the driver and binds a different driver to the interface? If +not then this code and be left as is, but I just wanted to be certain +since I know this isn't just enabling SR-IOV we are having to do a +number of other checks against the virtio device. diff --git a/a/content_digest b/N1/content_digest index 9de38bc..e3b61cc 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -23,30 +23,36 @@ " Zhihong <zhihong.wang@intel.com>\0" "\00:1\0" "b\0" - "T24gV2VkLCAyMDE4LTA1LTMwIGF0IDE5OjIyICswMzAwLCBNaWNoYWVsIFMuIFRzaXJraW4gd3Jv\n" - "dGU6DQo+IE9uIFdlZCwgTWF5IDMwLCAyMDE4IGF0IDA5OjEwOjU3QU0gLTA3MDAsIEFsZXhhbmRl\n" - "ciBEdXljayB3cm90ZToNCj4gPiBPbiBXZWQsIE1heSAzMCwgMjAxOCBhdCAxOjU1IEFNLCBUaXdl\n" - "aSBCaWUgPHRpd2VpLmJpZUBpbnRlbC5jb20+IHdyb3RlOg0KPiA+ID4gVGhlcmUgaXMgYSBuZXcg\n" - "ZmVhdHVyZSBiaXQgYWxsb2NhdGVkIGluIHZpcnRpbyBzcGVjIHRvDQo+ID4gPiBzdXBwb3J0IFNS\n" - "LUlPViAoU2luZ2xlIFJvb3QgSS9PIFZpcnR1YWxpemF0aW9uKToNCj4gPiA+IA0KPiA+ID4gaHR0\n" - "cHM6Ly9naXRodWIuY29tL29hc2lzLXRjcy92aXJ0aW8tc3BlYy9pc3N1ZXMvMTENCj4gPiA+IA0K\n" - "PiA+ID4gVGhpcyBwYXRjaCBlbmFibGVzIHRoZSBzdXBwb3J0IGZvciB0aGlzIGZlYXR1cmUgYml0\n" - "IGluDQo+ID4gPiB2aXJ0aW8gZHJpdmVyLg0KPiA+ID4gDQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBU\n" - "aXdlaSBCaWUgPHRpd2VpLmJpZUBpbnRlbC5jb20+DQo+ID4gDQo+ID4gU28gZnJvbSBhIHF1aWNr\n" - "IGdsYW5jZSBpdCBsb29rcyBsaWtlIHdlIGFyZSBsZWF2aW5nIFNSLUlPViBlbmFibGVkIGlmDQo+\n" - "ID4gdGhlIGRyaXZlciBpcyByZW1vdmVkLiBEbyB3ZSB3YW50IHRvIGhhdmUgdGhhdCBiZWhhdmlv\n" - "ciBvciBzaG91bGQgd2UNCj4gPiBiZSBhZGRpbmcgdGhlIGNvZGUgdG8gZGlzYWJsZSBTUi1JT1Yg\n" - "YW5kIGZyZWUgdGhlIFZGcyBvbiBkcml2ZXINCj4gPiByZW1vdmFsPw0KPiANCj4gQ291bGQgcGNp\n" - "IGNvcmUgaGFuZGxlIGl0IGZvciB1cyBzb21laG93Pw0KDQpNYXliZSwgYnV0IGl0IHdvdWxkIHJl\n" - "cXVpcmUgY2hhbmdlcyB0byB0aGUgcGNpIGNvcmUgdG8gZG8gaXQuDQoNClRoZSBwcm9ibGVtIGlz\n" - "IHNvbWUgZHJpdmVycyB3YW50IHRvIGxlYXZlIHRoZSBWRnMgdGhlcmUgc2luY2UgdGhlIFBGDQpk\n" - "b2Vzbid0IHJlYWxseSBkbyBhbnl0aGluZywgb3IgdGhleSBoYXZlIHRoZSBvcHRpb24gb2YgZXNz\n" - "ZW50aWFsbHkNCnB1dHRpbmcgdGhlIFZGcyBpbnRvIGEgc3RhbmRieSBzdGF0ZSB3aGVuIHRoZSBQ\n" - "RiBpcyBnb25lLg0KDQpNeSBtYWluIGNvbmNlcm4gaXMgZG8gd2UgY2FyZSBpZiBWRnMgYXJlIGFs\n" - "bG9jYXRlZCBhbmQgdGhlbiBzb21lYm9keQ0KcmVtb3ZlcyB0aGUgZHJpdmVyIGFuZCBiaW5kcyBh\n" - "IGRpZmZlcmVudCBkcml2ZXIgdG8gdGhlIGludGVyZmFjZT8gSWYNCm5vdCB0aGVuIHRoaXMgY29k\n" - "ZSBhbmQgYmUgbGVmdCBhcyBpcywgYnV0IEkganVzdCB3YW50ZWQgdG8gYmUgY2VydGFpbg0Kc2lu\n" - "Y2UgSSBrbm93IHRoaXMgaXNuJ3QganVzdCBlbmFibGluZyBTUi1JT1Ygd2UgYXJlIGhhdmluZyB0\n" - byBkbyBhDQpudW1iZXIgb2Ygb3RoZXIgY2hlY2tzIGFnYWluc3QgdGhlIHZpcnRpbyBkZXZpY2Uu + "On Wed, 2018-05-30 at 19:22 +0300, Michael S. Tsirkin wrote:\n" + "> On Wed, May 30, 2018 at 09:10:57AM -0700, Alexander Duyck wrote:\n" + "> > On Wed, May 30, 2018 at 1:55 AM, Tiwei Bie <tiwei.bie@intel.com> wrote:\n" + "> > > There is a new feature bit allocated in virtio spec to\n" + "> > > support SR-IOV (Single Root I/O Virtualization):\n" + "> > > \n" + "> > > https://github.com/oasis-tcs/virtio-spec/issues/11\n" + "> > > \n" + "> > > This patch enables the support for this feature bit in\n" + "> > > virtio driver.\n" + "> > > \n" + "> > > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>\n" + "> > \n" + "> > So from a quick glance it looks like we are leaving SR-IOV enabled if\n" + "> > the driver is removed. Do we want to have that behavior or should we\n" + "> > be adding the code to disable SR-IOV and free the VFs on driver\n" + "> > removal?\n" + "> \n" + "> Could pci core handle it for us somehow?\n" + "\n" + "Maybe, but it would require changes to the pci core to do it.\n" + "\n" + "The problem is some drivers want to leave the VFs there since the PF\n" + "doesn't really do anything, or they have the option of essentially\n" + "putting the VFs into a standby state when the PF is gone.\n" + "\n" + "My main concern is do we care if VFs are allocated and then somebody\n" + "removes the driver and binds a different driver to the interface? If\n" + "not then this code and be left as is, but I just wanted to be certain\n" + "since I know this isn't just enabling SR-IOV we are having to do a\n" + number of other checks against the virtio device. -ffa6479d04fd523a1a923c1df5d6e1eedd4ab3fe907e8ae2e4a8f1f053acd6dd +1aa42429990fcfda1a0875698c238c75327275e2adbee2bdfd347595d79c45ad
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.