virtio_pci: support enabling VFs
Subsystems (2)
PATCH 1/1 virtio_pci: support enabling VFs
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.
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.html
This patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238
drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)
drivers/virtio/virtio_pci_common.c +20 -0
@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,
@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);
drivers/virtio/virtio_pci_modern.c +14 -0
@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );
include/uapi/linux/virtio_config.h +6 -1
@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've
@@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */
Signature · 1 line
2.17.0
Quoted 13 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.html
Quoted 7 lines
This patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)
Looks good and matches the virtio spec change, but I'm not familiar with PCI SR-IOV details, so not a full Reviewed-by.
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Quoted 13 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.html
Quoted 7 lines
This patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)
Looks good and matches the virtio spec change, but I'm not familiar with PCI SR-IOV details, so not a full Reviewed-by.
Quoted 9 lines · Tiwei Bie
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 <[email protected]>
Quoted 108 lines
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +20
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-1@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ Signature · 1 line
2.17.0
Quoted 9 lines · Tiwei Bie
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 <[email protected]>
Quoted 108 lines
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +20
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-1@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ Signature · 1 line
2.17.0
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)
<snip>
include/uapi/linux/virtio_config.h
Quoted 5 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@
There is a value in the comment directly before this that should be updated as well to be consistent with the new value for VIRTIO_TRANSPORT_F_END below.
include/uapi/linux/virtio_config.h line 55
Quoted 8 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've
<snip>
--
Mark Rustad, Networking Division, Intel Corporation
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)
<snip>
include/uapi/linux/virtio_config.h
Quoted 5 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@
There is a value in the comment directly before this that should be updated as well to be consistent with the new value for VIRTIO_TRANSPORT_F_END below.
include/uapi/linux/virtio_config.h line 55
Quoted 8 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've
<snip>
--
Mark Rustad, Networking Division, Intel Corporation
Michael S. Tsirkin
maintainerQuoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers with VIRTIO_TRANSPORT_F_START and VIRTIO_TRANSPORT_F_END in the comment.
Maybe replace "e.g. virtio_ring" with "e.g. virtio_ring, virtio_pci etc." as well.
Quoted 13 lines
include/uapi/linux/virtio_config.h line 55
Quoted 8 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've <snip>
--
Mark Rustad, Networking Division, Intel Corporation
Michael S. Tsirkin
maintainerQuoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers with VIRTIO_TRANSPORT_F_START and VIRTIO_TRANSPORT_F_END in the comment.
Maybe replace "e.g. virtio_ring" with "e.g. virtio_ring, virtio_pci etc." as well.
Quoted 13 lines
include/uapi/linux/virtio_config.h line 55
Quoted 8 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've <snip>
--
Mark Rustad, Networking Division, Intel Corporation
Quoted 38 lines · Michael S. Tsirkin
Quoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.
Quoted 6 lines
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers withVIRTIO_TRANSPORT_F_STARTandVIRTIO_TRANSPORT_F_ENDin the comment.
Maybe replace "e.g.virtio_ring" with "e.g.virtio_ring,virtio_pcietc." as well.
Good idea! Thanks for the suggestion! I'll do it.
Best regards,
Tiwei Bie
Quoted 16 lines
Quoted 14 lines
include/uapi/linux/virtio_config.h line 55
Quoted 9 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've <snip>
--
Mark Rustad, Networking Division, Intel Corporation
Michael S. Tsirkin
maintainerQuoted 46 lines · Tiwei Bie
Quoted 38 lines · Michael S. Tsirkin
Quoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.Quoted 6 lines
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers withVIRTIO_TRANSPORT_F_STARTandVIRTIO_TRANSPORT_F_ENDin the comment.
Maybe replace "e.g.virtio_ring" with "e.g.virtio_ring,virtio_pcietc." as well.
Quoted 4 lines
Good idea! Thanks for the suggestion! I'll do it.
Best regards,
Tiwei Bie
Or just focus on the new feature, tweak start/end as a separate patch. Up to you, the important thing is to have a ready to roll patch before the merge window.
Quoted 17 lines
Quoted 17 lines
Quoted 15 lines
include/uapi/linux/virtio_config.h line 55
Quoted 10 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've <snip>
--
Mark Rustad, Networking Division, Intel Corporation
Michael S. Tsirkin
maintainerQuoted 46 lines · Tiwei Bie
Quoted 38 lines · Michael S. Tsirkin
Quoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.Quoted 6 lines
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers withVIRTIO_TRANSPORT_F_STARTandVIRTIO_TRANSPORT_F_ENDin the comment.
Maybe replace "e.g.virtio_ring" with "e.g.virtio_ring,virtio_pcietc." as well.
Quoted 4 lines
Good idea! Thanks for the suggestion! I'll do it.
Best regards,
Tiwei Bie
Or just focus on the new feature, tweak start/end as a separate patch. Up to you, the important thing is to have a ready to roll patch before the merge window.
Quoted 17 lines
Quoted 17 lines
Quoted 15 lines
include/uapi/linux/virtio_config.h line 55
Quoted 10 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've <snip>
--
Mark Rustad, Networking Division, Intel Corporation
Quoted 49 lines · Michael S. Tsirkin
Quoted 48 lines · Tiwei Bie
Quoted 38 lines · Michael S. Tsirkin
Quoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.Quoted 6 lines
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers withVIRTIO_TRANSPORT_F_STARTandVIRTIO_TRANSPORT_F_ENDin the comment.
Maybe replace "e.g.virtio_ring" with "e.g.virtio_ring,virtio_pcietc." as well.Good idea! Thanks for the suggestion! I'll do it.
Quoted 7 lines
Quoted 2 lines
Best regards,
Tiwei BieOr just focus on the new feature, tweak start/end as a separate patch. Up to you, the important thing is to have a ready to roll patch before the merge window.
Got it! Thank you very much!
Best regards,
Tiwei Bie
Quoted 49 lines · Michael S. Tsirkin
Quoted 48 lines · Tiwei Bie
Quoted 38 lines · Michael S. Tsirkin
Quoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.Quoted 6 lines
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers withVIRTIO_TRANSPORT_F_STARTandVIRTIO_TRANSPORT_F_ENDin the comment.
Maybe replace "e.g.virtio_ring" with "e.g.virtio_ring,virtio_pcietc." as well.Good idea! Thanks for the suggestion! I'll do it.
Quoted 7 lines
Quoted 2 lines
Best regards,
Tiwei BieOr just focus on the new feature, tweak start/end as a separate patch. Up to you, the important thing is to have a ready to roll patch before the merge window.
Got it! Thank you very much!
Best regards,
Tiwei Bie
Quoted 38 lines · Michael S. Tsirkin
Quoted 26 lines · Mark D
Quoted 21 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)<snip>
Quoted 10 lines
include/uapi/linux/virtio_config.h
Quoted 6 lines
include/uapi/linux/virtio_config.h +0
-0@@ -49,7 +49,7 @@There is a value in the comment directly before this that should be updated as well to be consistent with the new value for
VIRTIO_TRANSPORT_F_ENDbelow.
Quoted 6 lines
It hasn't been updated to 34 yet.
I suggest a separate patch to replace the numbers withVIRTIO_TRANSPORT_F_STARTandVIRTIO_TRANSPORT_F_ENDin the comment.
Maybe replace "e.g.virtio_ring" with "e.g.virtio_ring,virtio_pcietc." as well.
Good idea! Thanks for the suggestion! I'll do it.
Best regards,
Tiwei Bie
Quoted 16 lines
Quoted 14 lines
include/uapi/linux/virtio_config.h line 55
Quoted 9 lines
include/uapi/linux/virtio_config.h +1
-1* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've <snip>
--
Mark Rustad, Networking Division, Intel Corporation
Quoted 9 lines · Tiwei Bie
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 <[email protected]>
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?
Quoted 114 lines
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +20
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-2@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ --2.17.0
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 9 lines · Tiwei Bie
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 <[email protected]>
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?
Quoted 114 lines
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +20
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-2@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ --2.17.0
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Michael S. Tsirkin
maintainerQuoted 9 lines · Alexander Duyck
Quoted 8 lines · Tiwei Bie
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.
Quoted 6 lines
Quoted 1 line
Signed-off-by Tiwei Bie <[email protected]>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?
Quoted 114 lines
Quoted 114 lines
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +20
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-2@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ --2.17.0
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Michael S. Tsirkin
maintainerQuoted 9 lines · Alexander Duyck
Quoted 8 lines · Tiwei Bie
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.
Quoted 6 lines
Quoted 1 line
Signed-off-by Tiwei Bie <[email protected]>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?
Quoted 114 lines
Quoted 114 lines
---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +20
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ; + +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-2@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ --2.17.0
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Alexander Duyck
Quoted 8 lines · Tiwei Bie
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Signed-off-by Tiwei Bie <[email protected]>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.
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
Michael S. Tsirkin
maintainerQuoted 26 lines · Alexander H
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Alexander Duyck
Quoted 8 lines · Tiwei Bie
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Signed-off-by Tiwei Bie <[email protected]>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.
Quoted 5 lines
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.
Well the spec says features have to be negotiated, and since we reset the device when we unbind from it I think it's a given we should keep a driver bound to the PF.
IOW until we are sure we need the capability to keep it enabled, let's disable it to be safe.
Signature · 1 line
MST
Michael S. Tsirkin
maintainerQuoted 26 lines · Alexander H
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Alexander Duyck
Quoted 8 lines · Tiwei Bie
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Signed-off-by Tiwei Bie <[email protected]>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.
Quoted 5 lines
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.
Well the spec says features have to be negotiated, and since we reset the device when we unbind from it I think it's a given we should keep a driver bound to the PF.
IOW until we are sure we need the capability to keep it enabled, let's disable it to be safe.
Signature · 1 line
MST
Michael S. Tsirkin
maintainerQuoted 34 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +5
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs);
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 10 lines
drivers/virtio/virtio_pci_common.c +10
-0+ +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;
BTW what is all this trickery in aid of?
Quoted 73 lines
drivers/virtio/virtio_pci_common.c +5
-0+ +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-1@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ Signature · 1 line
2.17.0
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +8
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; +
Quoted 8 lines
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 6 lines
drivers/virtio/virtio_pci_common.c +6
-0+if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel, pci_sriov_configure_simple is #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.
--
Mark Rustad, Networking Division, Intel Corporation
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Quoted 21 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +8
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; +Quoted 8 lines
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 6 lines
drivers/virtio/virtio_pci_common.c +6
-0+if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
Quoted 4 lines
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
T24gV2VkLCAyMDE4LTA1LTMwIGF0IDA5OjQ0IC0wNzAwLCBSdXN0YWQsIE1hcmsgRCB3cm90ZToN Cj4gT24gTWF5IDMwLCAyMDE4LCBhdCA5OjIyIEFNLCBNaWNoYWVsIFMuIFRzaXJraW4gPG1zdEBy ZWRoYXQuY29tPiB3cm90ZToNCj4gDQo+ID4gPiArc3RhdGljIGludCB2aXJ0aW9fcGNpX3NyaW92 X2NvbmZpZ3VyZShzdHJ1Y3QgcGNpX2RldiAqcGNpX2RldiwgaW50ICANCj4gPiA+IG51bV92ZnMp DQo+ID4gPiArew0KPiA+ID4gKwlzdHJ1Y3QgdmlydGlvX3BjaV9kZXZpY2UgKnZwX2RldiA9IHBj aV9nZXRfZHJ2ZGF0YShwY2lfZGV2KTsNCj4gPiA+ICsJc3RydWN0IHZpcnRpb19kZXZpY2UgKnZk ZXYgPSAmdnBfZGV2LT52ZGV2Ow0KPiA+ID4gKwlpbnQgKCpzcmlvdl9jb25maWd1cmUpKHN0cnVj dCBwY2lfZGV2ICpwY2lfZGV2LCBpbnQgbnVtX3Zmcyk7DQo+ID4gPiArDQo+ID4gPiArCWlmICgh KHZkZXYtPmNvbmZpZy0+Z2V0X3N0YXR1cyh2ZGV2KSAmIFZJUlRJT19DT05GSUdfU19EUklWRVJf T0spKQ0KPiA+ID4gKwkJcmV0dXJuIC1FQlVTWTsNCj4gPiA+ICsNCj4gPiA+ICsJaWYgKCFfX3Zp cnRpb190ZXN0X2JpdCh2ZGV2LCBWSVJUSU9fRl9TUl9JT1YpKQ0KPiA+ID4gKwkJcmV0dXJuIC1F SU5WQUw7DQo+ID4gPiArDQo+ID4gPiArCXNyaW92X2NvbmZpZ3VyZSA9IHBjaV9zcmlvdl9jb25m aWd1cmVfc2ltcGxlOw0KPiA+ID4gKwlpZiAoc3Jpb3ZfY29uZmlndXJlID09IE5VTEwpDQo+ID4g PiArCQlyZXR1cm4gLUVOT0VOVDsNCj4gPiANCj4gPiBCVFcgd2hhdCBpcyBhbGwgdGhpcyB0cmlj a2VyeSBpbiBhaWQgb2Y/DQo+IA0KPiBXaGVuIFNSLUlPViBzdXBwb3J0IGlzIG5vdCBjb21waWxl ZCBpbnRvIHRoZSBrZXJuZWwsICANCj4gcGNpX3NyaW92X2NvbmZpZ3VyZV9zaW1wbGUgaXMgI2Rl ZmluZWQgYXMgTlVMTC4gVGhpcyBhbGxvd3MgaXQgdG8gY29tcGlsZSAgDQo+IGluIHRoYXQgY2Fz ZSwgZXZlbiB0aG91Z2ggdGhlcmUgaXMgdXR0ZXJseSBubyB3YXkgZm9yIGl0IHRvIGJlIGNhbGxl ZCBpbiAgDQo+IHRoYXQgY2FzZS4gSXQgaXMgYW4gYWx0ZXJuYXRpdmUgdG8gI2lmcyBpbiB0aGUg Y29kZS4NCg0KV2h5IGV2ZW4gaGF2ZSB0aGUgY2FsbCB0aG91Z2g/IEkgd291bGQgd3JhcCBhbGwg b2YgdGhpcyBpbiBhbiAjaWZkZWYNCmFuZCBzdHJpcCBpdCBvdXQgc2luY2UgeW91IGNvdWxkbid0 IHN1cHBvcnQgU1ItSU9WIGlmIGl0IGlzbid0IHByZXNlbnQNCmluIHRoZSBrZXJuZWwgYW55d2F5 Lg==
Quoted 22 lines · Alexander H
Quoted 21 lines · Mark D
Quoted 18 lines · Michael S. Tsirkin
Quoted 6 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +4
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs);drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 10 lines
drivers/virtio/virtio_pci_common.c +10
-0+ +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
Quoted 8 lines
Quoted 4 lines
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
--
Mark Rustad, Networking Division, Intel Corporation
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Quoted 30 lines · Mark D
Quoted 27 lines · Alexander H
Quoted 25 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +8
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; +Quoted 8 lines
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 6 lines
drivers/virtio/virtio_pci_common.c +6
-0+if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.
Quoted 7 lines
Quoted 3 lines
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
In my opinion, maybe it would be better to make pci_sriov_configure_simple() always available just like other sriov functions.
Based on the comments in the original patch:
https://patchwork.kernel.org/patch/10353197/
"""
+/* this is expected to be used as a function pointer, just define as NULL */ +#define pci_sriov_configure_simple NULL
"""
This function could be defined as NULL just because it was expected to be used as a function pointer. But actually it could be called directly as a function, just like this case.
So I prefer to make this function always available just like other sriov functions.
Best regards,
Tiwei Bie
Quoted 56 lines · Tiwei Bie
Quoted 30 lines · Mark D
Quoted 27 lines · Alexander H
Quoted 25 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +8
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; +Quoted 8 lines
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 6 lines
drivers/virtio/virtio_pci_common.c +6
-0+if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.Quoted 7 lines
Quoted 3 lines
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
In my opinion, maybe it would be better to make
pci_sriov_configure_simple()always available just like other sriov functions.Based on the comments in the original patch:
https://patchwork.kernel.org/patch/10353197/
"""(quoted diff) +2
-0+/* this is expected to be used as a function pointer, just define as NULL */ +#define pci_sriov_configure_simple NULL"""
This function could be defined as NULL just because it was expected to be used as a function pointer. But actually it could be called directly as a function, just like this case.
Quoted 5 lines
So I prefer to make this function always available just like other sriov functions.
Best regards,
Tiwei Bie
The fact that you are having to add additional code kind of implies that maybe this doesn't fall into the pci_sriov_configure_simple case anymore. The PF itself is defining what the VF can and can't do via the feature flags you are testing for.
For example how is the bit of code below valid if the kernel itself doesn't support SR-IOV:
+static void vp_transport_features(struct virtio_device *vdev, u64 features) +{
+ struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+ struct pci_dev *pci_dev = vp_dev->pci_dev;
+
+ if ((features & BIT_ULL(VIRTIO_F_SR_IOV)) &&
+ pci_find_ext_capability(pci_dev, PCI_EXT_CAP_ID_SRIOV))
+ __virtio_set_bit(vdev, VIRTIO_F_SR_IOV);
+}
+
It really seems like we should be wrapping these functions at the very minimum so that they don't imply you have SR-IOV support when it isn't supported in the kernel.
Also it seems like we should be disabling the VFs if the driver is unbound from this interface. We need to add logic to disable SR-IOV if the driver is removed. What we don't want to do is leave VFs allocated and then have the potential for us to unbind/rebind the driver as the new driver may change the negotiated features.
- Alex
Quoted 56 lines · Tiwei Bie
Quoted 30 lines · Mark D
Quoted 27 lines · Alexander H
Quoted 25 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +8
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; +Quoted 8 lines
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 6 lines
drivers/virtio/virtio_pci_common.c +6
-0+if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.Quoted 7 lines
Quoted 3 lines
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
In my opinion, maybe it would be better to make
pci_sriov_configure_simple()always available just like other sriov functions.Based on the comments in the original patch:
https://patchwork.kernel.org/patch/10353197/
"""(quoted diff) +2
-0+/* this is expected to be used as a function pointer, just define as NULL */ +#define pci_sriov_configure_simple NULL"""
This function could be defined as NULL just because it was expected to be used as a function pointer. But actually it could be called directly as a function, just like this case.
Quoted 5 lines
So I prefer to make this function always available just like other sriov functions.
Best regards,
Tiwei Bie
The fact that you are having to add additional code kind of implies that maybe this doesn't fall into the pci_sriov_configure_simple case anymore. The PF itself is defining what the VF can and can't do via the feature flags you are testing for.
For example how is the bit of code below valid if the kernel itself doesn't support SR-IOV:
+static void vp_transport_features(struct virtio_device *vdev, u64 features) +{
+ struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+ struct pci_dev *pci_dev = vp_dev->pci_dev;
+
+ if ((features & BIT_ULL(VIRTIO_F_SR_IOV)) &&
+ pci_find_ext_capability(pci_dev, PCI_EXT_CAP_ID_SRIOV))
+ __virtio_set_bit(vdev, VIRTIO_F_SR_IOV);
+}
+
It really seems like we should be wrapping these functions at the very minimum so that they don't imply you have SR-IOV support when it isn't supported in the kernel.
Also it seems like we should be disabling the VFs if the driver is unbound from this interface. We need to add logic to disable SR-IOV if the driver is removed. What we don't want to do is leave VFs allocated and then have the potential for us to unbind/rebind the driver as the new driver may change the negotiated features.
- Alex
Quoted 60 lines · Alexander Duyck
Quoted 59 lines · Tiwei Bie
Quoted 30 lines · Mark D
Quoted 27 lines · Alexander H
Quoted 25 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)(quoted diff) +8
-0+{ + struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev); + struct virtio_device *vdev = &vp_dev->vdev; + int (*sriov_configure)(struct pci_dev *pci_dev, int num_vfs); + + if (!(vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_DRIVER_OK)) + return -EBUSY; +Quoted 8 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+ if (!__virtio_test_bit(vdev, VIRTIO_F_SR_IOV)) + return -EINVAL; + + sriov_configure = pci_sriov_configure_simple; + if (sriov_configure == NULL) + return -ENOENT;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.Quoted 7 lines
Quoted 3 lines
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
In my opinion, maybe it would be better to make
pci_sriov_configure_simple()always available just like other sriov functions.Based on the comments in the original patch:
https://patchwork.kernel.org/patch/10353197/
"""(quoted diff) +2
-0+/* this is expected to be used as a function pointer, just define as NULL */ +#define pci_sriov_configure_simple NULL"""
This function could be defined as NULL just because it was expected to be used as a function pointer. But actually it could be called directly as a function, just like this case.
So I prefer to make this function always available just like other sriov functions.
Quoted 7 lines
Quoted 2 lines
Best regards,
Tiwei BieThe fact that you are having to add additional code kind of implies that maybe this doesn't fall into the
pci_sriov_configure_simplecase anymore. The PF itself is defining what the VF can and can't do via the feature flags you are testing for.
I think you're right about pci_sriov_configure_simple isn't designed for this case. I dropped the use of pci_sriov_configure_simple in v2. Thanks!
Quoted 14 lines
For example how is the bit of code below valid if the kernel itself doesn't support SR-IOV:
(quoted diff) +10
-0+static void vp_transport_features(struct virtio_device *vdev, u64 features) +{ + struct virtio_pci_device *vp_dev = to_vp_device(vdev); + struct pci_dev *pci_dev = vp_dev->pci_dev; + + if ((features & BIT_ULL(VIRTIO_F_SR_IOV)) && + pci_find_ext_capability(pci_dev, PCI_EXT_CAP_ID_SRIOV)) + __virtio_set_bit(vdev, VIRTIO_F_SR_IOV); +} +
Quoted 3 lines
It really seems like we should be wrapping these functions at the very minimum so that they don't imply you have SR-IOV support when it isn't supported in the kernel.
I think it's OK to accept this feature bit in this case. The IOV support not enabled in kernel just means there is no way for users to use SR-IOV. But it doesn't mean that the virtio driver doesn't understand *this feature bit*. Even if the IOV support is enabled in kernel, there is still no way for virtio driver to know whether users will enable VFs or not. Accepting this feature is to tell the device the virtio driver understands this feature (i.e. this is not an incompatible virtio driver). And it's not to tell the device whether users will enable VFs or not, or how many VFs will be enabled.
Quoted 6 lines
Also it seems like we should be disabling the VFs if the driver is unbound from this interface. We need to add logic to disable SR-IOV if the driver is removed. What we don't want to do is leave VFs allocated and then have the potential for us to unbind/rebind the driver as the new driver may change the negotiated features.
Right. Thanks!
FYI, here is v2:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00206.html
Best regards,
Tiwei Bie
Quoted 60 lines · Alexander Duyck
Quoted 59 lines · Tiwei Bie
Quoted 30 lines · Mark D
Quoted 27 lines · Alexander H
Quoted 25 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)(quoted diff) +8
-0+{ + struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev); + struct virtio_device *vdev = &vp_dev->vdev; + int (*sriov_configure)(struct pci_dev *pci_dev, int num_vfs); + + if (!(vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_DRIVER_OK)) + return -EBUSY; +Quoted 8 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+ if (!__virtio_test_bit(vdev, VIRTIO_F_SR_IOV)) + return -EINVAL; + + sriov_configure = pci_sriov_configure_simple; + if (sriov_configure == NULL) + return -ENOENT;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.Quoted 7 lines
Quoted 3 lines
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
In my opinion, maybe it would be better to make
pci_sriov_configure_simple()always available just like other sriov functions.Based on the comments in the original patch:
https://patchwork.kernel.org/patch/10353197/
"""(quoted diff) +2
-0+/* this is expected to be used as a function pointer, just define as NULL */ +#define pci_sriov_configure_simple NULL"""
This function could be defined as NULL just because it was expected to be used as a function pointer. But actually it could be called directly as a function, just like this case.
So I prefer to make this function always available just like other sriov functions.
Quoted 7 lines
Quoted 2 lines
Best regards,
Tiwei BieThe fact that you are having to add additional code kind of implies that maybe this doesn't fall into the
pci_sriov_configure_simplecase anymore. The PF itself is defining what the VF can and can't do via the feature flags you are testing for.
I think you're right about pci_sriov_configure_simple isn't designed for this case. I dropped the use of pci_sriov_configure_simple in v2. Thanks!
Quoted 14 lines
For example how is the bit of code below valid if the kernel itself doesn't support SR-IOV:
(quoted diff) +10
-0+static void vp_transport_features(struct virtio_device *vdev, u64 features) +{ + struct virtio_pci_device *vp_dev = to_vp_device(vdev); + struct pci_dev *pci_dev = vp_dev->pci_dev; + + if ((features & BIT_ULL(VIRTIO_F_SR_IOV)) && + pci_find_ext_capability(pci_dev, PCI_EXT_CAP_ID_SRIOV)) + __virtio_set_bit(vdev, VIRTIO_F_SR_IOV); +} +
Quoted 3 lines
It really seems like we should be wrapping these functions at the very minimum so that they don't imply you have SR-IOV support when it isn't supported in the kernel.
I think it's OK to accept this feature bit in this case. The IOV support not enabled in kernel just means there is no way for users to use SR-IOV. But it doesn't mean that the virtio driver doesn't understand *this feature bit*. Even if the IOV support is enabled in kernel, there is still no way for virtio driver to know whether users will enable VFs or not. Accepting this feature is to tell the device the virtio driver understands this feature (i.e. this is not an incompatible virtio driver). And it's not to tell the device whether users will enable VFs or not, or how many VFs will be enabled.
Quoted 6 lines
Also it seems like we should be disabling the VFs if the driver is unbound from this interface. We need to add logic to disable SR-IOV if the driver is removed. What we don't want to do is leave VFs allocated and then have the potential for us to unbind/rebind the driver as the new driver may change the negotiated features.
Right. Thanks!
FYI, here is v2:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00206.html
Best regards,
Tiwei Bie
Quoted 30 lines · Mark D
Quoted 27 lines · Alexander H
Quoted 25 lines · Mark D
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
+static int
virtio_pci_sriov_configure(struct pci_dev *pci_dev, int num_vfs)drivers/virtio/virtio_pci_common.c +8
-0+{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs); + +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; +Quoted 8 lines
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 6 lines
drivers/virtio/virtio_pci_common.c +6
-0+if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;BTW what is all this trickery in aid of?
When SR-IOV support is not compiled into the kernel,
pci_sriov_configure_simpleis #defined as NULL. This allows it to compile in that case, even though there is utterly no way for it to be called in that case. It is an alternative to #ifs in the code.
Quoted 7 lines
Quoted 3 lines
Why even have the call though? I would wrap all of this in an #ifdef and strip it out since you couldn't support SR-IOV if it isn't present in the kernel anyway.
I am inclined to agree. In this case, the presence of #ifdefs I think would be clearer. As written, someone will want to get rid of the pointer only to create a build problem when SR-IOV is not configured.
In my opinion, maybe it would be better to make pci_sriov_configure_simple() always available just like other sriov functions.
Based on the comments in the original patch:
https://patchwork.kernel.org/patch/10353197/
"""
+/* this is expected to be used as a function pointer, just define as NULL */ +#define pci_sriov_configure_simple NULL
"""
This function could be defined as NULL just because it was expected to be used as a function pointer. But actually it could be called directly as a function, just like this case.
So I prefer to make this function always available just like other sriov functions.
Best regards,
Tiwei Bie
Michael S. Tsirkin
maintainerQuoted 34 lines · Tiwei Bie
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 <[email protected]>---
This patch depends on below proposal:
https://lists.oasis-open.org/archives/virtio-dev/201805/msg00154.htmlThis patch depends on below patch:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8effc395c2097e258fcedfc02ed4a66d45fb4238drivers/virtio/virtio_pci_common.c | 20 ++++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 14 ++++++++++++++ include/uapi/linux/virtio_config.h | 7 ++++++- 3 files changed, 40 insertions(+), 1 deletion(-)drivers/virtio/virtio_pci_common.c +5
-0@@ -588,6 +588,25 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)put_device (dev); } +static int virtio_pci_sriov_configure (struct pci_dev *pci_dev,int num_vfs) +{ +struct virtio_pci_device *vp_dev =pci_get_drvdata (pci_dev); +struct virtio_device *vdev = &vp_dev->vdev; +int (*sriov_configure)(struct pci_dev *pci_dev,int num_vfs);
drivers/virtio/virtio_pci_common.c static void virtio_pci_remove(struct pci_dev *pci_dev) · line 605
Quoted 10 lines
drivers/virtio/virtio_pci_common.c +10
-0+ +if (!(vdev->config->get_status (vdev) &VIRTIO_CONFIG_S_DRIVER_OK )) +return -EBUSY ; + +if (!__virtio_test_bit (vdev,VIRTIO_F_SR_IOV )) +return -EINVAL ; + + sriov_configure = pci_sriov_configure_simple; +if (sriov_configure ==NULL ) +return -ENOENT ;
BTW what is all this trickery in aid of?
Quoted 73 lines
drivers/virtio/virtio_pci_common.c +5
-0+ +return sriov_configure (pci_dev, num_vfs); +} +static struct pci_driver virtio_pci_driver = { .name ="virtio-pci" , .id_table = virtio_pci_id_table,@@ -596,6 +615,7 @@ static struct pci_driver virtio_pci_driver = {#ifdef CONFIG_PM_SLEEP .driver.pm = &virtio_pci_pm_ops, #endif + .sriov_configure = virtio_pci_sriov_configure, };module_pci_driver (virtio_pci_driver);drivers/virtio/virtio_pci_modern.c +14
-0@@ -153,14 +153,28 @@ static u64 vp_get_features(struct virtio_device *vdev)return features; } +static void vp_transport_features (struct virtio_device *vdev,u64 features) +{ +struct virtio_pci_device *vp_dev =to_vp_device (vdev); +struct pci_dev *pci_dev = vp_dev->pci_dev; + +if ((features &BIT_ULL (VIRTIO_F_SR_IOV )) && +pci_find_ext_capability (pci_dev,PCI_EXT_CAP_ID_SRIOV )) +__virtio_set_bit (vdev,VIRTIO_F_SR_IOV ); +} +/* virtio config->finalize_features() implementation */ static int vp_finalize_features (struct virtio_device *vdev) {struct virtio_pci_device *vp_dev =to_vp_device (vdev); +u64 features = vdev->features;/* Give virtio_ring a chance to accept features. */ vring_transport_features (vdev); +/* Give virtio_pci a chance to accept features. */ +vp_transport_features (vdev, features); +if (!__virtio_test_bit (vdev,VIRTIO_F_VERSION_1 )) {dev_err (&vdev->dev,"virtio: device uses modern interface " "but does not have VIRTIO_F_VERSION_1\n" );include/uapi/linux/virtio_config.h +6
-1@@ -49,7 +49,7 @@* transport being used (eg. virtio_ring), the rest are per-device feature * bits. */ #define VIRTIO_TRANSPORT_F_START 28 -#define VIRTIO_TRANSPORT_F_END 34 +#define VIRTIO_TRANSPORT_F_END 38#ifndef VIRTIO_CONFIG_NO_LEGACY /* Do we get callbacks when the ring is completely used, even if we've @@ -71,4 +71,9 @@* this is for compatibility with legacy systems. */ #define VIRTIO_F_IOMMU_PLATFORM 33 + +/* +* Does the device support Single Root I/O Virtualization? +*/ +#define VIRTIO_F_SR_IOV 37#endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ Signature · 1 line
2.17.0