Add support for unmanaged SR-IOV

From: Alexander Duyck <[email protected]>

This patch adds a common configuration function called pci_sriov_configure_simple that will allow for managing VFs on devices where the PF is not capable of managing VF resources.

Signed-off-by Alexander Duyck <[email protected]>

---

v5: New patch replacing pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
Dropped bits related to autoprobe changes
v6: Defined pci_sriov_configure_simple as NULL if IOV is disabled
v7: Updated pci_sriov_configure_simple to drop need for err value
Fixed comment explaining why pci_sriov_configure_simple is NULL

 drivers/pci/iov.c   |   31 +++++++++++++++++++++++++++++++
 include/linux/pci.h |    3 +++
 2 files changed, 34 insertions(+)

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

---

v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
v7: No code change, added Reviewed-by

 drivers/virtio/virtio_pci_common.c |    1 +
 1 file changed, 1 insertion(+)

drivers/virtio/virtio_pci_common.c +1 -1

index 48d4d1cf1cb6..67a227fd7aa0 100644
@@ -596,6 +596,7 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
 #ifdef CONFIG_PM_SLEEP
 	.driver.pm	= &virtio_pci_pm_ops,
 #endif
+	.sriov_configure = pci_sriov_configure_simple,
 };
 
 module_pci_driver(virtio_pci_driver);
 
 
---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

Quoted 22 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Quoted 3 lines

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Also, I am guessing that hardware implementations will want to add things like stong memory barriers - I guess we will add new feature bits for that too down the road?

Quoted 27 lines · Michael S. Tsirkin

Quoted 25 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

Quoted 3 lines

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Yes. If nothing else you may not even need a feature bit depending on how things go.

One of the reasons why Mark called out the subvendor/subdevice was because that might be able to be used to identify the specific hardware that is providing the SR-IOV feature so in the future if it is added to virtio itself then you could exclude devices like this by just limiting things based on subvendor/subdevice IDs.

Quoted 3 lines

Also, I am guessing that hardware implementations will want to add things like stong memory barriers - I guess we will add new feature bits for that too down the road?

That piece I don't have visibility into at this time. Perhaps Dan might have more visibility into future plans on what this might need.

Thanks.

- Alex

Quoted 32 lines · Alexander Duyck

Quoted 30 lines · Michael S. Tsirkin

Quoted 17 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

Quoted 8 lines

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Quoted 2 lines

Yes. If nothing else you may not even need a feature bit depending on how things go.

OTOH if the interface is changed in an incompatible way, and old Linux will attempt to drive the new device since there is no check.

I think we should add a feature bit right away.

Quoted 33 lines · Michael S. Tsirkin

Quoted 32 lines · Alexander Duyck

Quoted 30 lines · Michael S. Tsirkin

Quoted 17 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

Quoted 8 lines

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Quoted 8 lines

Quoted 2 lines

Yes. If nothing else you may not even need a feature bit depending on how things go.

OTOH if the interface is changed in an incompatible way, and old Linux will attempt to drive the new device since there is no check.

I think we should add a feature bit right away.

I'm not sure why you would need a feature bit. The capability is controlled via PCI configuration space. If it is present the device has the capability. If it is not then it does not.

Basically if the PCI configuration space is not present then the sysfs entries will not be spawned and nothing will attempt to use this function.

- ALex

Quoted 51 lines · Alexander Duyck

Quoted 33 lines · Michael S. Tsirkin

Quoted 32 lines · Alexander Duyck

Quoted 30 lines · Michael S. Tsirkin

Quoted 17 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

Quoted 8 lines

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Quoted 8 lines

Quoted 2 lines

Yes. If nothing else you may not even need a feature bit depending on how things go.

OTOH if the interface is changed in an incompatible way, and old Linux will attempt to drive the new device since there is no check.

I think we should add a feature bit right away.

I'm not sure why you would need a feature bit. The capability is controlled via PCI configuration space. If it is present the device has the capability. If it is not then it does not.

Basically if the PCI configuration space is not present then the sysfs entries will not be spawned and nothing will attempt to use this function.

Quoted 1 line

- ALex

It's about compability with older guests which ignore the capability.

The feature is thus helpful so host knows whether guest supports VFs.

Quoted 57 lines · Michael S. Tsirkin

Quoted 47 lines · Alexander Duyck

Quoted 33 lines · Michael S. Tsirkin

Quoted 32 lines · Alexander Duyck

Quoted 30 lines · Michael S. Tsirkin

Quoted 17 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

Quoted 8 lines

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Quoted 8 lines

Quoted 2 lines

Yes. If nothing else you may not even need a feature bit depending on how things go.

OTOH if the interface is changed in an incompatible way, and old Linux will attempt to drive the new device since there is no check.

I think we should add a feature bit right away.

I'm not sure why you would need a feature bit. The capability is controlled via PCI configuration space. If it is present the device has the capability. If it is not then it does not.

Quoted 5 lines

Basically if the PCI configuration space is not present then the sysfs entries will not be spawned and nothing will attempt to use this function.

- ALex

It's about compability with older guests which ignore the capability.

Quoted 1 line

The feature is thus helpful so host knows whether guest supports VFs.

The thing is if the capability is ignored then the feature isn't used. So for SR-IOV it isn't an uncommon thing for there to be drivers for the PF floating around that do not support SR-IOV. In such cases SR-IOV just isn't used while the hardware could support it.

I would think in the case of virtio it would be the same kind of thing. Basically if SR-IOV is supported by the host then the capability would be present. If SR-IOV is supported by the guest then it would make use of the capability to spawn VFs. If either the capability isn't present, or the driver doesn't use it then you won't be able to spawn VFs in the guest.

Maybe I am missing something. Do you support dynamically changing the PCI configuration space for Virtio devices based on the presence of feature bits provided by the guest?

Also are you saying this patch set should wait on the feature bit to be added, or are you talking about doing this as some sort of follow-up?

- Alex

Quoted 60 lines · Alexander Duyck

Quoted 58 lines · Michael S. Tsirkin

Quoted 47 lines · Alexander Duyck

Quoted 33 lines · Michael S. Tsirkin

Quoted 32 lines · Alexander Duyck

Quoted 30 lines · Michael S. Tsirkin

Quoted 17 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

Quoted 8 lines

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

So if and when virtio PFs can manage the VFs, then we can add a feature bit for that?
Seems reasonable.

Quoted 8 lines

Quoted 2 lines

Yes. If nothing else you may not even need a feature bit depending on how things go.

OTOH if the interface is changed in an incompatible way, and old Linux will attempt to drive the new device since there is no check.

I think we should add a feature bit right away.

I'm not sure why you would need a feature bit. The capability is controlled via PCI configuration space. If it is present the device has the capability. If it is not then it does not.

Quoted 5 lines

Basically if the PCI configuration space is not present then the sysfs entries will not be spawned and nothing will attempt to use this function.

- ALex

It's about compability with older guests which ignore the capability.

The feature is thus helpful so host knows whether guest supports VFs.

Quoted 4 lines

The thing is if the capability is ignored then the feature isn't used. So for SR-IOV it isn't an uncommon thing for there to be drivers for the PF floating around that do not support SR-IOV. In such cases SR-IOV just isn't used while the hardware could support it.

Right but how come there are VF drivers but PF driver does not know about these?

And are there PF drivers that intentially do not enable SRIOV because it's known to be broken in some way?

Case in point I do think virtio want to limit this depending on a feature bit on general principles (the principle being that all extensions have feature bits).

There are security implications here - we previously relied on whitelisting after all.

Wouldn't it be safer to be a bit more careful and update the actual PF drivers? It's just one line per driver, but it can be done with an ack by driver maintainer. If/once we find out all drivers do have it, we can then change the default.

Quoted 10 lines

I would think in the case of virtio it would be the same kind of thing. Basically if SR-IOV is supported by the host then the capability would be present. If SR-IOV is supported by the guest then it would make use of the capability to spawn VFs. If either the capability isn't present, or the driver doesn't use it then you won't be able to spawn VFs in the guest.

Maybe I am missing something. Do you support dynamically changing the PCI configuration space for Virtio devices based on the presence of feature bits provided by the guest?

No. The point is that IMHO at least virtio - in absence of feature bit - to ignore VFs rather than assume they are safe to drive
in an unmanaged way.

Quoted 4 lines

Also are you saying this patch set should wait on the feature bit to be added, or are you talking about doing this as some sort of follow-up?

Quoted 1 line

- Alex

I think for virtio it should include the feature bit, yes. Adding feature bit is very easy - post a patch to the virtio TC mailing list, wait about a week to give people time to respond (two weeks if it is around holidays and such).

Quoted 4 lines

I think for virtio it should include the feature bit, yes. Adding feature bit is very easy - post a patch to the virtio TC mailing list, wait about a week to give people time to respond (two weeks if it is around holidays and such).

The problem is we are talking about hardware/FPGA, not software. Adding a feature bit means going back and updating RTL. The software side of things is easy, re-validating things after a hardware/FPGA change not so much.

If this is a hard requirement I may just drop the virtio patch, push what I have, and leave it to Mark/Dan to deal with the necessary RTL and code changes needed to support Virtio as I don't expect the turnaround to be as easy as just a patch.

Thanks.

- Alex

Quoted 15 lines · Alexander Duyck

Quoted 4 lines

I think for virtio it should include the feature bit, yes. Adding feature bit is very easy - post a patch to the virtio TC mailing list, wait about a week to give people time to respond (two weeks if it is around holidays and such).

The problem is we are talking about hardware/FPGA, not software. Adding a feature bit means going back and updating RTL. The software side of things is easy, re-validating things after a hardware/FPGA change not so much.

If this is a hard requirement I may just drop the virtio patch, push what I have, and leave it to Mark/Dan to deal with the necessary RTL and code changes needed to support Virtio as I don't expect the turnaround to be as easy as just a patch.

Quoted 3 lines

Thanks.

- Alex

Let's focus on virtio in this thread.

Involving the virtio TC in host/guest interface changes is a hard requirement. It's just too easy to create conflicts otherwise.

So you guys should have just sent the proposal to the TC when you were doing your RTL and you would have been in the clear.

Generally adding a feature bit with any extension is a good idea:
this way you merely reserve a feature bit for your feature through the TC and are more or less sure of forward and backward compatibility. It's incredibly easy.

But maybe it's not needed here. I am not making the decisions myself. Not too late: post to the TC list and let's see what the response is. Without a feature bit you are making a change affecting all future implementations without exception so the bar is a bit higher: you need to actually post a spec text proposal not just a patch showing how to use the feature, and TC needs to vote on it. Voting takes a week, review a week or two depending on change complexity.

Hope this helps,

--
MST

Quoted 16 lines · Michael S. Tsirkin

Quoted 15 lines · Alexander Duyck

Quoted 4 lines

I think for virtio it should include the feature bit, yes. Adding feature bit is very easy - post a patch to the virtio TC mailing list, wait about a week to give people time to respond (two weeks if it is around holidays and such).

The problem is we are talking about hardware/FPGA, not software. Adding a feature bit means going back and updating RTL. The software side of things is easy, re-validating things after a hardware/FPGA change not so much.

If this is a hard requirement I may just drop the virtio patch, push what I have, and leave it to Mark/Dan to deal with the necessary RTL and code changes needed to support Virtio as I don't expect the turnaround to be as easy as just a patch.

Quoted 5 lines

Quoted 3 lines

Thanks.

- Alex

Let's focus on virtio in this thread.

That is kind of what I was thinking, and why I was thinking it might make sense to make the virtio specific changes a separate patch set. I could get the PCI bits taken care of in the meantime since they effect genetic PCI, NVMe, and the Amazon ENA interfaces.

Quoted 5 lines

Involving the virtio TC in host/guest interface changes is a hard requirement. It's just too easy to create conflicts otherwise.

So you guys should have just sent the proposal to the TC when you were doing your RTL and you would have been in the clear.

Agreed. I believe I brought this up when I was originally asked to look into the coding for this.

Quoted 4 lines

Generally adding a feature bit with any extension is a good idea:
this way you merely reserve a feature bit for your feature through the TC and are more or less sure of forward and backward compatibility. It's incredibly easy.

Agreed, though in this case I am not sure it makes sense since this isn't necessarily something that is a Virtio feature itself. It is just a side effect of the fact that they are adding SR-IOV support to a device that happens to emulate Virtio NET and apparently their PF has to be identical to the VF other than the PCIe extended config space.

Quoted 8 lines

But maybe it's not needed here. I am not making the decisions myself. Not too late: post to the TC list and let's see what the response is. Without a feature bit you are making a change affecting all future implementations without exception so the bar is a bit higher: you need to actually post a spec text proposal not just a patch showing how to use the feature, and TC needs to vote on it. Voting takes a week, review a week or two depending on change complexity.

Quoted 4 lines

Hope this helps,

--
MST

I think I will leave this for Dan and Mark to handle since I am still not all that familiar with the hardware in use here. Once a decision has been made him and Mark could look at pushing either the one line patch or something more complex involving a feature flag.

Thanks.

Alex

But maybe it's not needed here. I am not making the decisions myself. Not too late: post to the TC list and let's see what the response is. Without a feature bit you are making a change affecting all future implementations without exception so the bar is a bit higher: you need to actually post a spec text proposal not just a patch showing how to use the feature, and TC needs to vote on it. Voting takes a week, review a week or two depending on change complexity.

Quoted 8 lines

I'm not sure why you would need a feature bit. The capability is controlled via PCI configuration space. If it is present the device has the capability. If it is not then it does not.

Basically if the PCI configuration space is not present then the sysfs entries will not be spawned and nothing will attempt to use this function.

Quoted 1 line

- ALex

It's about compability with older guests which ignore the capability.

The feature is thus helpful so host knows whether guest supports VFs.

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

---

v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
v7: No code change, added Reviewed-by

 drivers/virtio/virtio_pci_common.c |    1 +
 1 file changed, 1 insertion(+)

From: Alexander Duyck <[email protected]>

Hardware-realized virtio_pci devices can implement SR-IOV, so this patch enables its use. The device in question is an upcoming Intel NIC that implements both a virtio_net PF and virtio_net VFs. These are hardware realizations of what has been up to now been a software interface.

The device in question has the following 4-part PCI IDs:

PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe

The patch currently needs no check for device ID, because the callback will never be made for devices that do not assert the capability or when run on a platform incapable of SR-IOV.

One reason for this patch is because the hardware requires the vendor ID of a VF to be the same as the vendor ID of the PF that created it. So it seemed logical to simply have a fully-functioning virtio_net PF create the VFs. This patch makes that possible.

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Mark Rustad <[email protected]>

Signed-off-by Alexander Duyck <[email protected]>

---

v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
v7: No code change, added Reviewed-by

 drivers/virtio/virtio_pci_common.c |    1 +
 1 file changed, 1 insertion(+)

drivers/virtio/virtio_pci_common.c +1 -1

index 48d4d1cf1cb6..67a227fd7aa0 100644
@@ -596,6 +596,7 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
 #ifdef CONFIG_PM_SLEEP
 	.driver.pm	= &virtio_pci_pm_ops,
 #endif
+	.sriov_configure = pci_sriov_configure_simple,
 };
 
 module_pci_driver(virtio_pci_driver);
 
 
---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

This series is meant to add support for SR-IOV on devices when the VFs are not managed by the kernel. Examples of recent patches attempting to do this include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio - https://patchwork.kernel.org/patch/10103353/
uio - https://patchwork.kernel.org/patch/9974031/

Since this is quickly blowing up into a multi-driver problem it is probably best to implement this solution as generically as possible.

This series is an attempt to do that. What we do with this patch set is provide a generic framework to enable SR-IOV in the case that the PF driver doesn't support managing the VFs itself.

I based my patch set originally on the patch by Mark Rustad but there isn't much left after going through and cleaning out the bits that were no longer needed, and after incorporating the feedback from David Miller. At this point the only items to be fully reused was his patch description which is now present in patch 3 of the set.

This solution is limited in scope to just adding support for devices that provide no functionality for SR-IOV other than allocating the VFs by calling pci_enable_sriov. Previous sets had included patches for VFIO, but for now I am dropping that as the scope of that work is larger then I think I can take on at this time.

v2: Reduced scope back to just virtio_pci and vfio-pci
Broke into 3 patch set from single patch
Changed autoprobe behavior to always set when num_vfs is set non-zero
v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
v4: Dropped vfio-pci patch
Added ena and nvme to drivers now using pci_sriov_configure_unmanaged Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged
Added new patch that enables pci_sriov_configure_simple Updated drivers to use pci_sriov_configure_simple
v6: Defined pci_sriov_configure_simple as NULL when SR-IOV is not enabled
Updated drivers to drop "#ifdef" checks for IOV
Added pci-pf-stub as place for PF-only drivers to add support
v7: Dropped pci_id table explanation from pci-pf-stub driver
Updated pci_sriov_configure_simple to drop need for err value Fixed comment explaining why pci_sriov_configure_simple is NULL

Cc Mark Rustad <[email protected]>

Cc Maximilian Heyne <[email protected]>

Cc Liang-Min Wang <[email protected]>

Cc David Woodhouse <[email protected]>

---

Alexander Duyck (5):
pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
ena: Migrate over to unmanaged SR-IOV support
nvme: Migrate over to unmanaged SR-IOV support
pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs

  drivers/net/ethernet/amazon/ena/ena_netdev.c |   28 -------------
  drivers/nvme/host/pci.c                      |   20 ----------
  drivers/pci/Kconfig                          |   12 ++++++
  drivers/pci/Makefile                         |    2 +
  drivers/pci/iov.c                            |   31 +++++++++++++++
  drivers/pci/pci-pf-stub.c                    |   54 ++++++++++++++++++++++++++
  drivers/virtio/virtio_pci_common.c           |    1
  include/linux/pci.h                          |    3 +
  include/linux/pci_ids.h                      |    2 +
  9 files changed, 107 insertions(+), 46 deletions(-)

create mode 100644 drivers/pci/pci-pf-stub.c

--

This series is meant to add support for SR-IOV on devices when the VFs are not managed by the kernel. Examples of recent patches attempting to do this include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio - https://patchwork.kernel.org/patch/10103353/
uio - https://patchwork.kernel.org/patch/9974031/

Since this is quickly blowing up into a multi-driver problem it is probably best to implement this solution as generically as possible.

This series is an attempt to do that. What we do with this patch set is provide a generic framework to enable SR-IOV in the case that the PF driver doesn't support managing the VFs itself.

I based my patch set originally on the patch by Mark Rustad but there isn't much left after going through and cleaning out the bits that were no longer needed, and after incorporating the feedback from David Miller. At this point the only items to be fully reused was his patch description which is now present in patch 3 of the set.

This solution is limited in scope to just adding support for devices that provide no functionality for SR-IOV other than allocating the VFs by calling pci_enable_sriov. Previous sets had included patches for VFIO, but for now I am dropping that as the scope of that work is larger then I think I can take on at this time.

v2: Reduced scope back to just virtio_pci and vfio-pci
Broke into 3 patch set from single patch
Changed autoprobe behavior to always set when num_vfs is set non-zero
v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
v4: Dropped vfio-pci patch
Added ena and nvme to drivers now using pci_sriov_configure_unmanaged Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged

Added new patch that enables pci_sriov_configure_simple Updated drivers to use pci_sriov_configure_simple
v6: Defined pci_sriov_configure_simple as NULL when SR-IOV is not enabled
Updated drivers to drop "#ifdef" checks for IOV
Added pci-pf-stub as place for PF-only drivers to add support
v7: Dropped pci_id table explanation from pci-pf-stub driver
Updated pci_sriov_configure_simple to drop need for err value Fixed comment explaining why pci_sriov_configure_simple is NULL

Quoted 36 lines · Alexander Duyck

This series is meant to add support for SR-IOV on devices when the VFs are not managed by the kernel. Examples of recent patches attempting to do this include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio - https://patchwork.kernel.org/patch/10103353/
uio - https://patchwork.kernel.org/patch/9974031/

Since this is quickly blowing up into a multi-driver problem it is probably best to implement this solution as generically as possible.

This series is an attempt to do that. What we do with this patch set is provide a generic framework to enable SR-IOV in the case that the PF driver doesn't support managing the VFs itself.

I based my patch set originally on the patch by Mark Rustad but there isn't much left after going through and cleaning out the bits that were no longer needed, and after incorporating the feedback from David Miller. At this point the only items to be fully reused was his patch description which is now present in patch 3 of the set.

This solution is limited in scope to just adding support for devices that provide no functionality for SR-IOV other than allocating the VFs by calling pci_enable_sriov. Previous sets had included patches for VFIO, but for now I am dropping that as the scope of that work is larger then I think I can take on at this time.

v2: Reduced scope back to just virtio_pci and vfio-pci
Broke into 3 patch set from single patch
Changed autoprobe behavior to always set when num_vfs is set non-zero
v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
v4: Dropped vfio-pci patch
Added ena and nvme to drivers now using pci_sriov_configure_unmanaged Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged

Quoted 9 lines

Added new patch that enables pci_sriov_configure_simple Updated drivers to use pci_sriov_configure_simple
v6: Defined pci_sriov_configure_simple as NULL when SR-IOV is not enabled
Updated drivers to drop "#ifdef" checks for IOV
Added pci-pf-stub as place for PF-only drivers to add support
v7: Dropped pci_id table explanation from pci-pf-stub driver
Updated pci_sriov_configure_simple to drop need for err value Fixed comment explaining why pci_sriov_configure_simple is NULL

Just following up since this has been sitting in patchwork for just over a month now
(https://patchwork.ozlabs.org/project/linux-pci/list/?series=34034).
I'm just wondering what the expectation is on getting these pulled into the pci tree? I'm assuming that is the best place for these patches. Are there any concerns I still need to address or are these going to be pulled in at some point, and if so is there any ETA on when that will be?

Thanks.

- Alex