* [PATCH v16 01/13] hw/pci: Rename has_power to enabled
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device Akihiko Odaki
` (11 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
The renamed state will not only represent powering state of PFs, but
also represent SR-IOV VF enablement in the future.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
include/hw/pci/pci.h | 7 ++++++-
include/hw/pci/pci_device.h | 2 +-
hw/pci/pci.c | 14 +++++++-------
hw/pci/pci_host.c | 4 ++--
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index eb26cac81098..fe04b4fafd04 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -678,6 +678,11 @@ static inline void pci_irq_pulse(PCIDevice *pci_dev)
}
MSIMessage pci_get_msi_message(PCIDevice *dev, int vector);
-void pci_set_power(PCIDevice *pci_dev, bool state);
+void pci_set_enabled(PCIDevice *pci_dev, bool state);
+
+static inline void pci_set_power(PCIDevice *pci_dev, bool state)
+{
+ pci_set_enabled(pci_dev, state);
+}
#endif
diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
index 15694f248948..f38fb3111954 100644
--- a/include/hw/pci/pci_device.h
+++ b/include/hw/pci/pci_device.h
@@ -57,7 +57,7 @@ typedef struct PCIReqIDCache PCIReqIDCache;
struct PCIDevice {
DeviceState qdev;
bool partially_hotplugged;
- bool has_power;
+ bool enabled;
/* PCI config space */
uint8_t *config;
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index fab86d056721..b532888e8f6c 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1525,7 +1525,7 @@ static void pci_update_mappings(PCIDevice *d)
continue;
new_addr = pci_bar_address(d, i, r->type, r->size);
- if (!d->has_power) {
+ if (!d->enabled) {
new_addr = PCI_BAR_UNMAPPED;
}
@@ -1613,7 +1613,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val_in, int
pci_update_irq_disabled(d, was_irq_disabled);
memory_region_set_enabled(&d->bus_master_enable_region,
(pci_get_word(d->config + PCI_COMMAND)
- & PCI_COMMAND_MASTER) && d->has_power);
+ & PCI_COMMAND_MASTER) && d->enabled);
}
msi_write_config(d, addr, val_in, l);
@@ -2884,18 +2884,18 @@ MSIMessage pci_get_msi_message(PCIDevice *dev, int vector)
return msg;
}
-void pci_set_power(PCIDevice *d, bool state)
+void pci_set_enabled(PCIDevice *d, bool state)
{
- if (d->has_power == state) {
+ if (d->enabled == state) {
return;
}
- d->has_power = state;
+ d->enabled = state;
pci_update_mappings(d);
memory_region_set_enabled(&d->bus_master_enable_region,
(pci_get_word(d->config + PCI_COMMAND)
- & PCI_COMMAND_MASTER) && d->has_power);
- if (!d->has_power) {
+ & PCI_COMMAND_MASTER) && d->enabled);
+ if (!d->enabled) {
pci_device_reset(d);
}
}
diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c
index dfe6fe618401..0d82727cc9dd 100644
--- a/hw/pci/pci_host.c
+++ b/hw/pci/pci_host.c
@@ -86,7 +86,7 @@ void pci_host_config_write_common(PCIDevice *pci_dev, uint32_t addr,
* allowing direct removal of unexposed functions.
*/
if ((pci_dev->qdev.hotplugged && !pci_get_function_0(pci_dev)) ||
- !pci_dev->has_power || is_pci_dev_ejected(pci_dev)) {
+ !pci_dev->enabled || is_pci_dev_ejected(pci_dev)) {
return;
}
@@ -111,7 +111,7 @@ uint32_t pci_host_config_read_common(PCIDevice *pci_dev, uint32_t addr,
* allowing direct removal of unexposed functions.
*/
if ((pci_dev->qdev.hotplugged && !pci_get_function_0(pci_dev)) ||
- !pci_dev->has_power || is_pci_dev_ejected(pci_dev)) {
+ !pci_dev->enabled || is_pci_dev_ejected(pci_dev)) {
return ~0x0;
}
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 01/13] hw/pci: Rename has_power to enabled Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-18 14:27 ` Cédric Le Goater
2024-09-13 3:44 ` [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF Akihiko Odaki
` (10 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
Disabled means it is a disabled SR-IOV VF or it is powered off, and
hidden from the guest.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/ppc/spapr_pci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 7cf9904c3546..f63182a03c41 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1296,6 +1296,10 @@ static void spapr_dt_pci_device_cb(PCIBus *bus, PCIDevice *pdev,
return;
}
+ if (!pdev->enabled) {
+ return;
+ }
+
err = spapr_dt_pci_device(p->sphb, pdev, p->fdt, p->offset);
if (err < 0) {
p->err = err;
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device
2024-09-13 3:44 ` [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device Akihiko Odaki
@ 2024-09-18 14:27 ` Cédric Le Goater
2024-09-19 4:32 ` Harsh Prateek Bora
2024-10-11 17:22 ` Shivaprasad G Bhat
0 siblings, 2 replies; 28+ messages in thread
From: Cédric Le Goater @ 2024-09-18 14:27 UTC (permalink / raw)
To: Akihiko Odaki, Philippe Mathieu-Daudé, Michael S. Tsirkin,
Marcel Apfelbaum, Alex Williamson, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman, Harsh Prateek Bora,
Shivaprasad G Bhat
Cc: qemu-devel, qemu-block
Hello,
Adding :
Harsh for QEMU/PPC pseries machine,
Shivaprasad for KVM/PPC VFIO and IOMMU support.
Could you please give us your feedback on these changes ?
Thanks,
C.
On 9/13/24 05:44, Akihiko Odaki wrote:
> Disabled means it is a disabled SR-IOV VF or it is powered off, and
> hidden from the guest.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> hw/ppc/spapr_pci.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 7cf9904c3546..f63182a03c41 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1296,6 +1296,10 @@ static void spapr_dt_pci_device_cb(PCIBus *bus, PCIDevice *pdev,
> return;
> }
>
> + if (!pdev->enabled) {
> + return;
> + }
> +
> err = spapr_dt_pci_device(p->sphb, pdev, p->fdt, p->offset);
> if (err < 0) {
> p->err = err;
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device
2024-09-18 14:27 ` Cédric Le Goater
@ 2024-09-19 4:32 ` Harsh Prateek Bora
2024-10-11 17:22 ` Shivaprasad G Bhat
1 sibling, 0 replies; 28+ messages in thread
From: Harsh Prateek Bora @ 2024-09-19 4:32 UTC (permalink / raw)
To: Cédric Le Goater, Akihiko Odaki, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman,
Shivaprasad G Bhat
Cc: qemu-devel, qemu-block
On 9/18/24 19:57, Cédric Le Goater wrote:
> Hello,
>
> Adding :
>
> Harsh for QEMU/PPC pseries machine,
> Shivaprasad for KVM/PPC VFIO and IOMMU support.
>
> Could you please give us your feedback on these changes ?
>
> Thanks,
>
> C.
>
>
>
> On 9/13/24 05:44, Akihiko Odaki wrote:
>> Disabled means it is a disabled SR-IOV VF or it is powered off, and
>> hidden from the guest.
>>
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>> hw/ppc/spapr_pci.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>> index 7cf9904c3546..f63182a03c41 100644
>> --- a/hw/ppc/spapr_pci.c
>> +++ b/hw/ppc/spapr_pci.c
>> @@ -1296,6 +1296,10 @@ static void spapr_dt_pci_device_cb(PCIBus *bus,
>> PCIDevice *pdev,
>> return;
>> }
>> + if (!pdev->enabled) {
>> + return;
>> + }
>> +
While I will let Shivaprasad comment from IO perspective, I would like
to suggest merging this condition with the error condition check
preceding it.
regards,
Harsh
>> err = spapr_dt_pci_device(p->sphb, pdev, p->fdt, p->offset);
>> if (err < 0) {
>> p->err = err;
>>
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device
2024-09-18 14:27 ` Cédric Le Goater
2024-09-19 4:32 ` Harsh Prateek Bora
@ 2024-10-11 17:22 ` Shivaprasad G Bhat
2024-10-14 16:26 ` Shivaprasad G Bhat
1 sibling, 1 reply; 28+ messages in thread
From: Shivaprasad G Bhat @ 2024-10-11 17:22 UTC (permalink / raw)
To: Cédric Le Goater, Akihiko Odaki, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman,
Harsh Prateek Bora
Cc: qemu-devel, qemu-block
On 9/18/24 7:57 PM, Cédric Le Goater wrote:
> Hello,
>
> Adding :
>
> Harsh for QEMU/PPC pseries machine,
> Shivaprasad for KVM/PPC VFIO and IOMMU support.
>
> Could you please give us your feedback on these changes ?
>
> Thanks,
>
> C.
>
>
>
> On 9/13/24 05:44, Akihiko Odaki wrote:
>> Disabled means it is a disabled SR-IOV VF or it is powered off, and
>> hidden from the guest.
I see you are taking care of not powering on VFs in the following 8th
patch in
the series. Without it, this patch doesn't hold. Hope this patch and the
8th patch
go together.
Reviewed-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Thanks,
Shivaprasad
>>
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>> hw/ppc/spapr_pci.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>> index 7cf9904c3546..f63182a03c41 100644
>> --- a/hw/ppc/spapr_pci.c
>> +++ b/hw/ppc/spapr_pci.c
>> @@ -1296,6 +1296,10 @@ static void spapr_dt_pci_device_cb(PCIBus
>> *bus, PCIDevice *pdev,
>> return;
>> }
>> + if (!pdev->enabled) {
>> + return;
>> + }
>> err = spapr_dt_pci_device(p->sphb, pdev, p->fdt, p->offset);
>> if (err < 0) {
>> p->err = err;
>>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device
2024-10-11 17:22 ` Shivaprasad G Bhat
@ 2024-10-14 16:26 ` Shivaprasad G Bhat
0 siblings, 0 replies; 28+ messages in thread
From: Shivaprasad G Bhat @ 2024-10-14 16:26 UTC (permalink / raw)
To: Cédric Le Goater, Akihiko Odaki, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman,
Harsh Prateek Bora
Cc: qemu-devel, qemu-block
On 10/11/24 10:52 PM, Shivaprasad G Bhat wrote:
>
> On 9/18/24 7:57 PM, Cédric Le Goater wrote:
>> Hello,
>>
>> Adding :
>>
>> Harsh for QEMU/PPC pseries machine,
>> Shivaprasad for KVM/PPC VFIO and IOMMU support.
>>
>> Could you please give us your feedback on these changes ?
>>
>> Thanks,
>>
>> C.
>>
>>
>>
>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>> Disabled means it is a disabled SR-IOV VF or it is powered off, and
>>> hidden from the guest.
>
> I see you are taking care of not powering on VFs in the following 8th
> patch in
>
> the series. Without it, this patch doesn't hold. Hope this patch and
> the 8th patch
>
> go together.
>
>
> Reviewed-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
>
>
While review/testing the patch again with the [8/13], I see the same
check is needed
in spapr_pci_dt_populate() before the call to spapr_dt_pci_device() to
take care of the
hotplug path. Kindly add the same there too. So, my Review-by would be
with that.
Thanks,
Shivaprasad
> Thanks,
>
> Shivaprasad
>
>>>
>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>> ---
>>> hw/ppc/spapr_pci.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>>> index 7cf9904c3546..f63182a03c41 100644
>>> --- a/hw/ppc/spapr_pci.c
>>> +++ b/hw/ppc/spapr_pci.c
>>> @@ -1296,6 +1296,10 @@ static void spapr_dt_pci_device_cb(PCIBus
>>> *bus, PCIDevice *pdev,
>>> return;
>>> }
>>> + if (!pdev->enabled) {
>>> + return;
>>> + }
>>> err = spapr_dt_pci_device(p->sphb, pdev, p->fdt, p->offset);
>>> if (err < 0) {
>>> p->err = err;
>>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 01/13] hw/pci: Rename has_power to enabled Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 02/13] hw/ppc/spapr_pci: Do not create DT for disabled PCI device Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-18 14:27 ` Cédric Le Goater
2024-09-13 3:44 ` [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs Akihiko Odaki
` (9 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
A PF may automatically create VFs and the PF may be function 0.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/ppc/spapr_pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index f63182a03c41..ed4454bbf79e 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1573,7 +1573,9 @@ static void spapr_pci_pre_plug(HotplugHandler *plug_handler,
* hotplug, we do not allow functions to be hotplugged to a
* slot that already has function 0 present
*/
- if (plugged_dev->hotplugged && bus->devices[PCI_DEVFN(slotnr, 0)] &&
+ if (plugged_dev->hotplugged &&
+ !pci_is_vf(pdev) &&
+ bus->devices[PCI_DEVFN(slotnr, 0)] &&
PCI_FUNC(pdev->devfn) != 0) {
error_setg(errp, "PCI: slot %d function 0 already occupied by %s,"
" additional functions can no longer be exposed to guest.",
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF
2024-09-13 3:44 ` [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF Akihiko Odaki
@ 2024-09-18 14:27 ` Cédric Le Goater
2024-10-11 17:22 ` Shivaprasad G Bhat
0 siblings, 1 reply; 28+ messages in thread
From: Cédric Le Goater @ 2024-09-18 14:27 UTC (permalink / raw)
To: Akihiko Odaki, Philippe Mathieu-Daudé, Michael S. Tsirkin,
Marcel Apfelbaum, Alex Williamson, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman, Harsh Prateek Bora,
Shivaprasad G Bhat
Cc: qemu-devel, qemu-block
Adding :
Harsh for QEMU/PPC pseries machine,
Shivaprasad for KVM/PPC VFIO and IOMMU support.
Thanks,
C.
On 9/13/24 05:44, Akihiko Odaki wrote:
> A PF may automatically create VFs and the PF may be function 0.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> hw/ppc/spapr_pci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index f63182a03c41..ed4454bbf79e 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1573,7 +1573,9 @@ static void spapr_pci_pre_plug(HotplugHandler *plug_handler,
> * hotplug, we do not allow functions to be hotplugged to a
> * slot that already has function 0 present
> */
> - if (plugged_dev->hotplugged && bus->devices[PCI_DEVFN(slotnr, 0)] &&
> + if (plugged_dev->hotplugged &&
> + !pci_is_vf(pdev) &&
> + bus->devices[PCI_DEVFN(slotnr, 0)] &&
> PCI_FUNC(pdev->devfn) != 0) {
> error_setg(errp, "PCI: slot %d function 0 already occupied by %s,"
> " additional functions can no longer be exposed to guest.",
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF
2024-09-18 14:27 ` Cédric Le Goater
@ 2024-10-11 17:22 ` Shivaprasad G Bhat
2024-10-12 12:10 ` Akihiko Odaki
0 siblings, 1 reply; 28+ messages in thread
From: Shivaprasad G Bhat @ 2024-10-11 17:22 UTC (permalink / raw)
To: Cédric Le Goater, Akihiko Odaki, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman,
Harsh Prateek Bora
Cc: qemu-devel, qemu-block
On 9/18/24 7:57 PM, Cédric Le Goater wrote:
> Adding :
>
> Harsh for QEMU/PPC pseries machine,
> Shivaprasad for KVM/PPC VFIO and IOMMU support.
>
> Thanks,
>
> C.
>
>
> On 9/13/24 05:44, Akihiko Odaki wrote:
>> A PF may automatically create VFs and the PF may be function 0.
>>
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>> hw/ppc/spapr_pci.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>> index f63182a03c41..ed4454bbf79e 100644
>> --- a/hw/ppc/spapr_pci.c
>> +++ b/hw/ppc/spapr_pci.c
>> @@ -1573,7 +1573,9 @@ static void spapr_pci_pre_plug(HotplugHandler
>> *plug_handler,
>> * hotplug, we do not allow functions to be hotplugged to a
>> * slot that already has function 0 present
>> */
>> - if (plugged_dev->hotplugged && bus->devices[PCI_DEVFN(slotnr,
>> 0)] &&
>> + if (plugged_dev->hotplugged &&
>> + !pci_is_vf(pdev) &&
I see there is history to this change. The reverted[1] virtio-net-pci
SRIOV emulation support
needed this as the VFs were explicitly specified with -device
virtio-net-pci,sriov-pf=X
property. I see the pre_plug handlers for the VFs cant be reached now
with the reverted
code base for the other devices(nvme and igb) supporting the SRIOV
emulation.
Do the VFs really reach this path in today's code base ? Other than the
above
workflow, the pre_plug() handlers wont be called for VFs when the
echo X > /<sys-fs-pf-path>/sriov_numvfs inside the guest too. I don't
see the
workflow(PF automatically creating VFs) to hit this path. Could you
clarify how?
I see before the revert of virito-net-pci sriov use-case, the out of
order VF hot|cold
plug post PF are prevented here. Even if we allowed VFs to continue
here, PFs were
prevented in pcie_sriov_register_device() which is followed sequentially
anyway. Now,
as the pcie_sriov_register_device() is no longer there, this check
actually makes
sense as this would be the only place we avoid the out of order plugging.
On a side note, for testing this fulky on PPC, we need more work on Qemu
today as the
open-sriov[2] is supported only on PowerVM.
Thanks,
Shivaprasad
Reference :
[1] - Atleast till commit b0fdaee5d1
[2] -
https://lore.kernel.org/linuxppc-dev/20180105164552.36371-1-bryantly@linux.vnet.ibm.com/
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF
2024-10-11 17:22 ` Shivaprasad G Bhat
@ 2024-10-12 12:10 ` Akihiko Odaki
2024-10-14 16:21 ` Shivaprasad G Bhat
0 siblings, 1 reply; 28+ messages in thread
From: Akihiko Odaki @ 2024-10-12 12:10 UTC (permalink / raw)
To: Shivaprasad G Bhat, Cédric Le Goater,
Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Paolo Bonzini, Daniel P. Berrangé,
Eduardo Habkost, Sriram Yagnaraman, Jason Wang, Keith Busch,
Klaus Jensen, Markus Armbruster, Matthew Rosato, Eric Farman,
Harsh Prateek Bora
Cc: qemu-devel, qemu-block
On 2024/10/12 2:22, Shivaprasad G Bhat wrote:
> On 9/18/24 7:57 PM, Cédric Le Goater wrote:
>> Adding :
>>
>> Harsh for QEMU/PPC pseries machine,
>> Shivaprasad for KVM/PPC VFIO and IOMMU support.
>>
>> Thanks,
>>
>> C.
>>
>>
>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>> A PF may automatically create VFs and the PF may be function 0.
>>>
>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>> ---
>>> hw/ppc/spapr_pci.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>>> index f63182a03c41..ed4454bbf79e 100644
>>> --- a/hw/ppc/spapr_pci.c
>>> +++ b/hw/ppc/spapr_pci.c
>>> @@ -1573,7 +1573,9 @@ static void spapr_pci_pre_plug(HotplugHandler
>>> *plug_handler,
>>> * hotplug, we do not allow functions to be hotplugged to a
>>> * slot that already has function 0 present
>>> */
>>> - if (plugged_dev->hotplugged && bus->devices[PCI_DEVFN(slotnr,
>>> 0)] &&
>>> + if (plugged_dev->hotplugged &&
>>> + !pci_is_vf(pdev) &&
>
> I see there is history to this change. The reverted[1] virtio-net-pci
> SRIOV emulation support
>
> needed this as the VFs were explicitly specified with -device virtio-
> net-pci,sriov-pf=X
>
> property. I see the pre_plug handlers for the VFs cant be reached now
> with the reverted
>
> code base for the other devices(nvme and igb) supporting the SRIOV
> emulation.
>
>
> Do the VFs really reach this path in today's code base ? Other than the
> above
>
> workflow, the pre_plug() handlers wont be called for VFs when the
>
> echo X > /<sys-fs-pf-path>/sriov_numvfs inside the guest too. I don't
> see the
>
> workflow(PF automatically creating VFs) to hit this path. Could you
> clarify how?
>
>
> I see before the revert of virito-net-pci sriov use-case, the out of
> order VF hot|cold
>
> plug post PF are prevented here. Even if we allowed VFs to continue
> here, PFs were
>
> prevented in pcie_sriov_register_device() which is followed sequentially
> anyway. Now,
>
> as the pcie_sriov_register_device() is no longer there, this check
> actually makes
>
> sense as this would be the only place we avoid the out of order plugging.
VFs are always plugged after its paired PF. Currently, VFs are plugged
when the guest writes sriov_numvfs. With "[PATCH v16 08/13] pcie_sriov:
Reuse SR-IOV VF device instances", which follows this patch, VFs will
plug while the PF is being realized.
I have no idea why you can't reproduce the issue by writing
sriov_numvfs, but it is easy to reproduce it with "[PATCH v16 08/13]
pcie_sriov: Reuse SR-IOV VF device instances" applied. You can use the
following command:
qemu-system-ppc64 -nographic -monitor stdio -serial none <<< 'device_add
igb'
It should say:
Error: PCI: slot 18 function 0 already occupied by igbvf, additional
functions can no longer be exposed to guest.
Regards,
Akihiko Odaki
>
>
> On a side note, for testing this fulky on PPC, we need more work on Qemu
> today as the
>
> open-sriov[2] is supported only on PowerVM.
>
>
> Thanks,
>
> Shivaprasad
>
>
> Reference :
>
> [1] - Atleast till commit b0fdaee5d1
>
> [2] - https://lore.kernel.org/linuxppc-dev/20180105164552.36371-1-
> bryantly@linux.vnet.ibm.com/
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF
2024-10-12 12:10 ` Akihiko Odaki
@ 2024-10-14 16:21 ` Shivaprasad G Bhat
0 siblings, 0 replies; 28+ messages in thread
From: Shivaprasad G Bhat @ 2024-10-14 16:21 UTC (permalink / raw)
To: Akihiko Odaki, Cédric Le Goater, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman,
Harsh Prateek Bora
Cc: qemu-devel, qemu-block
On 10/12/24 5:40 PM, Akihiko Odaki wrote:
> On 2024/10/12 2:22, Shivaprasad G Bhat wrote:
>> On 9/18/24 7:57 PM, Cédric Le Goater wrote:
>>> Adding :
>>>
>>> Harsh for QEMU/PPC pseries machine,
>>> Shivaprasad for KVM/PPC VFIO and IOMMU support.
>>>
>>> Thanks,
>>>
>>> C.
>>>
>>>
>>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>>> A PF may automatically create VFs and the PF may be function 0.
>>>>
>>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>>> ---
>>>> hw/ppc/spapr_pci.c | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>>>> index f63182a03c41..ed4454bbf79e 100644
>>>> --- a/hw/ppc/spapr_pci.c
>>>> +++ b/hw/ppc/spapr_pci.c
>>>> @@ -1573,7 +1573,9 @@ static void spapr_pci_pre_plug(HotplugHandler
>>>> *plug_handler,
>>>> * hotplug, we do not allow functions to be hotplugged to a
>>>> * slot that already has function 0 present
>>>> */
>>>> - if (plugged_dev->hotplugged && bus->devices[PCI_DEVFN(slotnr,
>>>> 0)] &&
>>>> + if (plugged_dev->hotplugged &&
>>>> + !pci_is_vf(pdev) &&
>>
>> I see there is history to this change. The reverted[1] virtio-net-pci
>> SRIOV emulation support
>>
>> needed this as the VFs were explicitly specified with -device virtio-
>> net-pci,sriov-pf=X
>>
>> property. I see the pre_plug handlers for the VFs cant be reached now
>> with the reverted
>>
>> code base for the other devices(nvme and igb) supporting the SRIOV
>> emulation.
>>
>>
>> Do the VFs really reach this path in today's code base ? Other than
>> the above
>>
>> workflow, the pre_plug() handlers wont be called for VFs when the
>>
>> echo X > /<sys-fs-pf-path>/sriov_numvfs inside the guest too. I don't
>> see the
>>
>> workflow(PF automatically creating VFs) to hit this path. Could you
>> clarify how?
>>
>>
>> I see before the revert of virito-net-pci sriov use-case, the out of
>> order VF hot|cold
>>
>> plug post PF are prevented here. Even if we allowed VFs to continue
>> here, PFs were
>>
>> prevented in pcie_sriov_register_device() which is followed
>> sequentially anyway. Now,
>>
>> as the pcie_sriov_register_device() is no longer there, this check
>> actually makes
>>
>> sense as this would be the only place we avoid the out of order
>> plugging.
>
> VFs are always plugged after its paired PF. Currently, VFs are plugged
> when the guest writes sriov_numvfs. With "[PATCH v16 08/13]
> pcie_sriov: Reuse SR-IOV VF device instances", which follows this
> patch, VFs will plug while the PF is being realized.
>
Thanks, I was juggling between the reverted patches and the current ones
and missed this patch. I see things fine now.
Reviewed-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> I have no idea why you can't reproduce the issue by writing sriov_numvfs,
On PPC64, IOV resources are disabled and the sriov attributes in sysfs are
not accessible without open-sriov support [2](not yet added on qemu).
However, the config space is showing the IOV capabilities and the values
fine with the patches.
> but it is easy to reproduce it with "[PATCH v16 08/13] pcie_sriov:
> Reuse SR-IOV VF device instances" applied. You can use the following
> command:
> qemu-system-ppc64 -nographic -monitor stdio -serial none <<<
> 'device_add igb'
>
> It should say:
> Error: PCI: slot 18 function 0 already occupied by igbvf, additional
> functions can no longer be exposed to guest.
>
> Regards,
> Akihiko Odaki
>
>>
>>
>> On a side note, for testing this fulky on PPC, we need more work on
>> Qemu today as the
>>
>> open-sriov[2] is supported only on PowerVM.
>>
>>
>> Thanks,
>>
>> Shivaprasad
>>
>>
>> Reference :
>>
>> [1] - Atleast till commit b0fdaee5d1
>>
>> [2] - https://lore.kernel.org/linuxppc-dev/20180105164552.36371-1-
>> bryantly@linux.vnet.ibm.com/
>>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (2 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 03/13] hw/ppc/spapr_pci: Do not reject VFs created after a PF Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-18 15:02 ` Cédric Le Goater
2024-09-13 3:44 ` [PATCH v16 05/13] s390x/pci: Allow plugging SR-IOV devices Akihiko Odaki
` (8 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
VFs are automatically created by PF, and creating zpci for them will
result in unexpected usage of fids. Currently QEMU does not support
multifunction for s390x so we don't need zpci for VFs anyway.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 3e57d5faca18..1a620f5b2a04 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -1080,6 +1080,16 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
pbdev = s390_pci_find_dev_by_target(s, dev->id);
if (!pbdev) {
+ /*
+ * VFs are automatically created by PF, and creating zpci for them
+ * will result in unexpected usage of fids. Currently QEMU does not
+ * support multifunction for s390x so we don't need zpci for VFs
+ * anyway.
+ */
+ if (pci_is_vf(pdev)) {
+ return;
+ }
+
pbdev = s390_pci_device_new(s, dev->id, errp);
if (!pbdev) {
return;
@@ -1167,7 +1177,9 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
int32_t devfn;
pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
- g_assert(pbdev);
+ if (!pbdev) {
+ return;
+ }
s390_pci_generate_plug_event(HP_EVENT_STANDBY_TO_RESERVED,
pbdev->fh, pbdev->fid);
@@ -1206,7 +1218,10 @@ static void s390_pcihost_unplug_request(HotplugHandler *hotplug_dev,
* we've checked the PCI device already (to prevent endless recursion).
*/
pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
- g_assert(pbdev);
+ if (!pbdev) {
+ return;
+ }
+
pbdev->pci_unplug_request_processed = true;
qdev_unplug(DEVICE(pbdev), errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-09-13 3:44 ` [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs Akihiko Odaki
@ 2024-09-18 15:02 ` Cédric Le Goater
2024-09-18 15:32 ` Akihiko Odaki
0 siblings, 1 reply; 28+ messages in thread
From: Cédric Le Goater @ 2024-09-18 15:02 UTC (permalink / raw)
To: Akihiko Odaki, Philippe Mathieu-Daudé, Michael S. Tsirkin,
Marcel Apfelbaum, Alex Williamson, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block
Hello,
On 9/13/24 05:44, Akihiko Odaki wrote:
> VFs are automatically created by PF, and creating zpci for them will
> result in unexpected usage of fids. Currently QEMU does not support
> multifunction for s390x so we don't need zpci for VFs anyway.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 3e57d5faca18..1a620f5b2a04 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -1080,6 +1080,16 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>
> pbdev = s390_pci_find_dev_by_target(s, dev->id);
> if (!pbdev) {
> + /*
> + * VFs are automatically created by PF, and creating zpci for them
> + * will result in unexpected usage of fids. Currently QEMU does not
> + * support multifunction for s390x so we don't need zpci for VFs
> + * anyway.
> + */
> + if (pci_is_vf(pdev)) {
> + return;
> + }
> +
> pbdev = s390_pci_device_new(s, dev->id, errp);
> if (!pbdev) {
> return;
> @@ -1167,7 +1177,9 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
> int32_t devfn;
>
> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
> - g_assert(pbdev);
> + if (!pbdev) {
> + return;
> + }
I don't understand this change. Could you please explain ?
Thanks,
C.
> s390_pci_generate_plug_event(HP_EVENT_STANDBY_TO_RESERVED,
> pbdev->fh, pbdev->fid);
> @@ -1206,7 +1218,10 @@ static void s390_pcihost_unplug_request(HotplugHandler *hotplug_dev,
> * we've checked the PCI device already (to prevent endless recursion).
> */
> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
> - g_assert(pbdev);
> + if (!pbdev) {
> + return;
> + }
> +
> pbdev->pci_unplug_request_processed = true;
> qdev_unplug(DEVICE(pbdev), errp);
> } else if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-09-18 15:02 ` Cédric Le Goater
@ 2024-09-18 15:32 ` Akihiko Odaki
2024-10-10 15:44 ` Cédric Le Goater
0 siblings, 1 reply; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-18 15:32 UTC (permalink / raw)
To: Cédric Le Goater, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block
On 2024/09/18 17:02, Cédric Le Goater wrote:
> Hello,
>
> On 9/13/24 05:44, Akihiko Odaki wrote:
>> VFs are automatically created by PF, and creating zpci for them will
>> result in unexpected usage of fids. Currently QEMU does not support
>> multifunction for s390x so we don't need zpci for VFs anyway.
>>
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>> hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>> index 3e57d5faca18..1a620f5b2a04 100644
>> --- a/hw/s390x/s390-pci-bus.c
>> +++ b/hw/s390x/s390-pci-bus.c
>> @@ -1080,6 +1080,16 @@ static void s390_pcihost_plug(HotplugHandler
>> *hotplug_dev, DeviceState *dev,
>> pbdev = s390_pci_find_dev_by_target(s, dev->id);
>> if (!pbdev) {
>> + /*
>> + * VFs are automatically created by PF, and creating zpci
>> for them
>> + * will result in unexpected usage of fids. Currently
>> QEMU does not
>> + * support multifunction for s390x so we don't need zpci
>> for VFs
>> + * anyway.
>> + */
>> + if (pci_is_vf(pdev)) {
>> + return;
>> + }
>> +
>> pbdev = s390_pci_device_new(s, dev->id, errp);
>> if (!pbdev) {
>> return;
>> @@ -1167,7 +1177,9 @@ static void s390_pcihost_unplug(HotplugHandler
>> *hotplug_dev, DeviceState *dev,
>> int32_t devfn;
>> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
>> - g_assert(pbdev);
>> + if (!pbdev) {
>> + return;
>> + }
>
>
> I don't understand this change. Could you please explain ?
We need to tolerate that pbdev being NULL because VFs do no longer have
zpci and pbdev will be NULL for them.
Regards,
Akihiko Odaki
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-09-18 15:32 ` Akihiko Odaki
@ 2024-10-10 15:44 ` Cédric Le Goater
2024-10-12 11:05 ` Akihiko Odaki
0 siblings, 1 reply; 28+ messages in thread
From: Cédric Le Goater @ 2024-10-10 15:44 UTC (permalink / raw)
To: Akihiko Odaki, Philippe Mathieu-Daudé, Michael S. Tsirkin,
Marcel Apfelbaum, Alex Williamson, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block
Hello Akihiko,
Sorry for the late reply.
On 9/18/24 17:32, Akihiko Odaki wrote:
> On 2024/09/18 17:02, Cédric Le Goater wrote:
>> Hello,
>>
>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>> VFs are automatically created by PF, and creating zpci for them will
>>> result in unexpected usage of fids. Currently QEMU does not support
>>> multifunction for s390x so we don't need zpci for VFs anyway.
>>>
>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>> ---
>>> hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
>>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>>> index 3e57d5faca18..1a620f5b2a04 100644
>>> --- a/hw/s390x/s390-pci-bus.c
>>> +++ b/hw/s390x/s390-pci-bus.c
>>> @@ -1080,6 +1080,16 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>>> pbdev = s390_pci_find_dev_by_target(s, dev->id);
>>> if (!pbdev) {
>>> + /*
>>> + * VFs are automatically created by PF, and creating zpci for them
>>> + * will result in unexpected usage of fids. Currently QEMU does not
>>> + * support multifunction for s390x so we don't need zpci for VFs
>>> + * anyway.
>>> + */
>>> + if (pci_is_vf(pdev)) {
>>> + return;
>>> + }
>>> +
>>> pbdev = s390_pci_device_new(s, dev->id, errp);
>>> if (!pbdev) {
>>> return;
>>> @@ -1167,7 +1177,9 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
>>> int32_t devfn;
>>> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
>>> - g_assert(pbdev);
>>> + if (!pbdev) {
>>> + return;
>>> + }
>>
>>
>> I don't understand this change. Could you please explain ?
>
> We need to tolerate that pbdev being NULL because VFs do no longer have zpci and pbdev will be NULL for them.
Then, I think we should extend the assert with a check on pci_is_vf(pdev)
to be symmetric with the plug handler and also, use the 'Error**' parameter
to report an error.
Thanks,
C.
>
> Regards,
> Akihiko Odaki
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-10-10 15:44 ` Cédric Le Goater
@ 2024-10-12 11:05 ` Akihiko Odaki
2024-10-14 8:43 ` Cédric Le Goater
0 siblings, 1 reply; 28+ messages in thread
From: Akihiko Odaki @ 2024-10-12 11:05 UTC (permalink / raw)
To: Cédric Le Goater, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block
On 2024/10/11 0:44, Cédric Le Goater wrote:
> Hello Akihiko,
>
> Sorry for the late reply.
>
> On 9/18/24 17:32, Akihiko Odaki wrote:
>> On 2024/09/18 17:02, Cédric Le Goater wrote:
>>> Hello,
>>>
>>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>>> VFs are automatically created by PF, and creating zpci for them will
>>>> result in unexpected usage of fids. Currently QEMU does not support
>>>> multifunction for s390x so we don't need zpci for VFs anyway.
>>>>
>>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>>> ---
>>>> hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
>>>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>>>> index 3e57d5faca18..1a620f5b2a04 100644
>>>> --- a/hw/s390x/s390-pci-bus.c
>>>> +++ b/hw/s390x/s390-pci-bus.c
>>>> @@ -1080,6 +1080,16 @@ static void s390_pcihost_plug(HotplugHandler
>>>> *hotplug_dev, DeviceState *dev,
>>>> pbdev = s390_pci_find_dev_by_target(s, dev->id);
>>>> if (!pbdev) {
>>>> + /*
>>>> + * VFs are automatically created by PF, and creating
>>>> zpci for them
>>>> + * will result in unexpected usage of fids. Currently
>>>> QEMU does not
>>>> + * support multifunction for s390x so we don't need
>>>> zpci for VFs
>>>> + * anyway.
>>>> + */
>>>> + if (pci_is_vf(pdev)) {
>>>> + return;
>>>> + }
>>>> +
>>>> pbdev = s390_pci_device_new(s, dev->id, errp);
>>>> if (!pbdev) {
>>>> return;
>>>> @@ -1167,7 +1177,9 @@ static void s390_pcihost_unplug(HotplugHandler
>>>> *hotplug_dev, DeviceState *dev,
>>>> int32_t devfn;
>>>> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
>>>> - g_assert(pbdev);
>>>> + if (!pbdev) {
>>>> + return;
>>>> + }
>>>
>>>
>>> I don't understand this change. Could you please explain ?
>>
>> We need to tolerate that pbdev being NULL because VFs do no longer
>> have zpci and pbdev will be NULL for them.
>
> Then, I think we should extend the assert with a check on pci_is_vf(pdev)
> to be symmetric with the plug handler and also, use the 'Error**' parameter
> to report an error.
This should never happen unless there is a programming error so plain
g_assert() without error reporting should be fine. We don't need to
report an error when it is VF; we just don't have a work to do and
nothing wrong happens here.
Regards,
Akihiko Odaki
>
> Thanks,
>
> C.
>
>
>
>
>>
>> Regards,
>> Akihiko Odaki
>>
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-10-12 11:05 ` Akihiko Odaki
@ 2024-10-14 8:43 ` Cédric Le Goater
2024-10-18 4:29 ` Akihiko Odaki
0 siblings, 1 reply; 28+ messages in thread
From: Cédric Le Goater @ 2024-10-14 8:43 UTC (permalink / raw)
To: Akihiko Odaki, Philippe Mathieu-Daudé, Michael S. Tsirkin,
Marcel Apfelbaum, Alex Williamson, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block
Hello Akihiko,
On 10/12/24 13:05, Akihiko Odaki wrote:
> On 2024/10/11 0:44, Cédric Le Goater wrote:
>> Hello Akihiko,
>>
>> Sorry for the late reply.
>>
>> On 9/18/24 17:32, Akihiko Odaki wrote:
>>> On 2024/09/18 17:02, Cédric Le Goater wrote:
>>>> Hello,
>>>>
>>>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>>>> VFs are automatically created by PF, and creating zpci for them will
>>>>> result in unexpected usage of fids. Currently QEMU does not support
>>>>> multifunction for s390x so we don't need zpci for VFs anyway.
>>>>>
>>>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>>>> ---
>>>>> hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
>>>>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>>>>> index 3e57d5faca18..1a620f5b2a04 100644
>>>>> --- a/hw/s390x/s390-pci-bus.c
>>>>> +++ b/hw/s390x/s390-pci-bus.c
>>>>> @@ -1080,6 +1080,16 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>>>>> pbdev = s390_pci_find_dev_by_target(s, dev->id);
>>>>> if (!pbdev) {
>>>>> + /*
>>>>> + * VFs are automatically created by PF, and creating zpci for them
>>>>> + * will result in unexpected usage of fids. Currently QEMU does not
>>>>> + * support multifunction for s390x so we don't need zpci for VFs
>>>>> + * anyway.
>>>>> + */
>>>>> + if (pci_is_vf(pdev)) {
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> pbdev = s390_pci_device_new(s, dev->id, errp);
>>>>> if (!pbdev) {
>>>>> return;
>>>>> @@ -1167,7 +1177,9 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
>>>>> int32_t devfn;
>>>>> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
>>>>> - g_assert(pbdev);
>>>>> + if (!pbdev) {
>>>>> + return;
>>>>> + }
>>>>
>>>>
>>>> I don't understand this change. Could you please explain ?
>>>
>>> We need to tolerate that pbdev being NULL because VFs do no longer have zpci and pbdev will be NULL for them.
>>
>> Then, I think we should extend the assert with a check on pci_is_vf(pdev)
>> to be symmetric with the plug handler and also, use the 'Error**' parameter
>> to report an error.
>
> This should never happen unless there is a programming error so plain g_assert() without error reporting should be fine. We don't need to report an error when it is VF; we just don't have a work to do and nothing wrong happens here.
unplugging a VF is still an invalid thing to do, reporting an error is preferable IMO.
Thanks,
C.
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs
2024-10-14 8:43 ` Cédric Le Goater
@ 2024-10-18 4:29 ` Akihiko Odaki
0 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-10-18 4:29 UTC (permalink / raw)
To: Cédric Le Goater, Philippe Mathieu-Daudé,
Michael S. Tsirkin, Marcel Apfelbaum, Alex Williamson,
Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Sriram Yagnaraman, Jason Wang, Keith Busch, Klaus Jensen,
Markus Armbruster, Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block
On 2024/10/14 17:43, Cédric Le Goater wrote:
> Hello Akihiko,
>
> On 10/12/24 13:05, Akihiko Odaki wrote:
>> On 2024/10/11 0:44, Cédric Le Goater wrote:
>>> Hello Akihiko,
>>>
>>> Sorry for the late reply.
>>>
>>> On 9/18/24 17:32, Akihiko Odaki wrote:
>>>> On 2024/09/18 17:02, Cédric Le Goater wrote:
>>>>> Hello,
>>>>>
>>>>> On 9/13/24 05:44, Akihiko Odaki wrote:
>>>>>> VFs are automatically created by PF, and creating zpci for them will
>>>>>> result in unexpected usage of fids. Currently QEMU does not support
>>>>>> multifunction for s390x so we don't need zpci for VFs anyway.
>>>>>>
>>>>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>>>>>> ---
>>>>>> hw/s390x/s390-pci-bus.c | 19 +++++++++++++++++--
>>>>>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>>>>>> index 3e57d5faca18..1a620f5b2a04 100644
>>>>>> --- a/hw/s390x/s390-pci-bus.c
>>>>>> +++ b/hw/s390x/s390-pci-bus.c
>>>>>> @@ -1080,6 +1080,16 @@ static void
>>>>>> s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
>>>>>> pbdev = s390_pci_find_dev_by_target(s, dev->id);
>>>>>> if (!pbdev) {
>>>>>> + /*
>>>>>> + * VFs are automatically created by PF, and creating
>>>>>> zpci for them
>>>>>> + * will result in unexpected usage of fids. Currently
>>>>>> QEMU does not
>>>>>> + * support multifunction for s390x so we don't need
>>>>>> zpci for VFs
>>>>>> + * anyway.
>>>>>> + */
>>>>>> + if (pci_is_vf(pdev)) {
>>>>>> + return;
>>>>>> + }
>>>>>> +
>>>>>> pbdev = s390_pci_device_new(s, dev->id, errp);
>>>>>> if (!pbdev) {
>>>>>> return;
>>>>>> @@ -1167,7 +1177,9 @@ static void
>>>>>> s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
>>>>>> int32_t devfn;
>>>>>> pbdev = s390_pci_find_dev_by_pci(s, PCI_DEVICE(dev));
>>>>>> - g_assert(pbdev);
>>>>>> + if (!pbdev) {
>>>>>> + return;
>>>>>> + }
>>>>>
>>>>>
>>>>> I don't understand this change. Could you please explain ?
>>>>
>>>> We need to tolerate that pbdev being NULL because VFs do no longer
>>>> have zpci and pbdev will be NULL for them.
>>>
>>> Then, I think we should extend the assert with a check on
>>> pci_is_vf(pdev)
>>> to be symmetric with the plug handler and also, use the 'Error**'
>>> parameter
>>> to report an error.
>>
>> This should never happen unless there is a programming error so plain
>> g_assert() without error reporting should be fine. We don't need to
>> report an error when it is VF; we just don't have a work to do and
>> nothing wrong happens here.
>
> unplugging a VF is still an invalid thing to do, reporting an error is
> preferable IMO.
Unplugging a VF will happen if you unplug igb, and it is a valid operation.
Regards,
Akihiko Odaki
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v16 05/13] s390x/pci: Allow plugging SR-IOV devices
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (3 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 04/13] s390x/pci: Avoid creating zpci for VFs Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 06/13] s390x/pci: Check for multifunction after device realization Akihiko Odaki
` (7 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
The guest cannot use VFs due to the lack of multifunction support but
can use PFs.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/s390x/s390-pci-bus.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 1a620f5b2a04..eab9a4f97830 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -974,7 +974,14 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
PCIDevice *pdev = PCI_DEVICE(dev);
- if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION) {
+ /*
+ * Multifunction is not supported due to the lack of CLP. However,
+ * do not check for multifunction capability for SR-IOV devices because
+ * SR-IOV devices automatically add the multifunction capability whether
+ * the user intends to use the functions other than the PF.
+ */
+ if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION &&
+ !pdev->exp.sriov_cap) {
error_setg(errp, "multifunction not supported in s390");
return;
}
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 06/13] s390x/pci: Check for multifunction after device realization
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (4 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 05/13] s390x/pci: Allow plugging SR-IOV devices Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 07/13] pcie_sriov: Do not manually unrealize Akihiko Odaki
` (6 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
The SR-IOV PFs set the multifunction bit during device realization so
check them after that. There is no functional change because we
explicitly ignore the multifunction bit for SR-IOV devices.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/s390x/s390-pci-bus.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index eab9a4f97830..e645192562ae 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -971,21 +971,7 @@ static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
"this device");
}
- if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
- PCIDevice *pdev = PCI_DEVICE(dev);
-
- /*
- * Multifunction is not supported due to the lack of CLP. However,
- * do not check for multifunction capability for SR-IOV devices because
- * SR-IOV devices automatically add the multifunction capability whether
- * the user intends to use the functions other than the PF.
- */
- if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION &&
- !pdev->exp.sriov_cap) {
- error_setg(errp, "multifunction not supported in s390");
- return;
- }
- } else if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
+ if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
S390PCIBusDevice *pbdev = S390_PCI_DEVICE(dev);
if (!s390_pci_alloc_idx(s, pbdev)) {
@@ -1076,6 +1062,18 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
pdev = PCI_DEVICE(dev);
+ /*
+ * Multifunction is not supported due to the lack of CLP. However,
+ * do not check for multifunction capability for SR-IOV devices because
+ * SR-IOV devices automatically add the multifunction capability whether
+ * the user intends to use the functions other than the PF.
+ */
+ if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION &&
+ !pdev->exp.sriov_cap) {
+ error_setg(errp, "multifunction not supported in s390");
+ return;
+ }
+
if (!dev->id) {
/* In the case the PCI device does not define an id */
/* we generate one based on the PCI address */
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 07/13] pcie_sriov: Do not manually unrealize
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (5 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 06/13] s390x/pci: Check for multifunction after device realization Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 08/13] pcie_sriov: Reuse SR-IOV VF device instances Akihiko Odaki
` (5 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
A device gets automatically unrealized when being unparented.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/pci/pcie_sriov.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index e9b23221d713..499becd5273f 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci/pcie_sriov.c
@@ -204,11 +204,7 @@ static void unregister_vfs(PCIDevice *dev)
trace_sriov_unregister_vfs(dev->name, PCI_SLOT(dev->devfn),
PCI_FUNC(dev->devfn), num_vfs);
for (i = 0; i < num_vfs; i++) {
- Error *err = NULL;
PCIDevice *vf = dev->exp.sriov_pf.vf[i];
- if (!object_property_set_bool(OBJECT(vf), "realized", false, &err)) {
- error_reportf_err(err, "Failed to unplug: ");
- }
object_unparent(OBJECT(vf));
object_unref(OBJECT(vf));
}
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 08/13] pcie_sriov: Reuse SR-IOV VF device instances
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (6 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 07/13] pcie_sriov: Do not manually unrealize Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 09/13] pcie_sriov: Release VFs failed to realize Akihiko Odaki
` (4 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
Disable SR-IOV VF devices by reusing code to power down PCI devices
instead of removing them when the guest requests to disable VFs. This
allows to realize devices and report VF realization errors at PF
realization time.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
docs/pcie_sriov.txt | 8 ++--
include/hw/pci/pci.h | 5 ---
include/hw/pci/pci_device.h | 15 +++++++
include/hw/pci/pcie_sriov.h | 6 +--
hw/net/igb.c | 13 ++++--
hw/nvme/ctrl.c | 24 +++++++----
hw/pci/pci.c | 2 +-
hw/pci/pcie_sriov.c | 102 +++++++++++++++++++-------------------------
8 files changed, 95 insertions(+), 80 deletions(-)
diff --git a/docs/pcie_sriov.txt b/docs/pcie_sriov.txt
index a47aad0bfab0..ab2142807f79 100644
--- a/docs/pcie_sriov.txt
+++ b/docs/pcie_sriov.txt
@@ -52,9 +52,11 @@ setting up a BAR for a VF.
...
/* Add and initialize the SR/IOV capability */
- pcie_sriov_pf_init(d, 0x200, "your_virtual_dev",
- vf_devid, initial_vfs, total_vfs,
- fun_offset, stride);
+ if (!pcie_sriov_pf_init(d, 0x200, "your_virtual_dev",
+ vf_devid, initial_vfs, total_vfs,
+ fun_offset, stride, errp)) {
+ return;
+ }
/* Set up individual VF BARs (parameters as for normal BARs) */
pcie_sriov_pf_init_vf_bar( ... )
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index fe04b4fafd04..14a869eeaa71 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -680,9 +680,4 @@ static inline void pci_irq_pulse(PCIDevice *pci_dev)
MSIMessage pci_get_msi_message(PCIDevice *dev, int vector);
void pci_set_enabled(PCIDevice *pci_dev, bool state);
-static inline void pci_set_power(PCIDevice *pci_dev, bool state)
-{
- pci_set_enabled(pci_dev, state);
-}
-
#endif
diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
index f38fb3111954..1ff3ce94e25b 100644
--- a/include/hw/pci/pci_device.h
+++ b/include/hw/pci/pci_device.h
@@ -212,6 +212,21 @@ static inline uint16_t pci_get_bdf(PCIDevice *dev)
return PCI_BUILD_BDF(pci_bus_num(pci_get_bus(dev)), dev->devfn);
}
+static inline void pci_set_power(PCIDevice *pci_dev, bool state)
+{
+ /*
+ * Don't change the enabled state of VFs when powering on/off the device.
+ *
+ * When powering on, VFs must not be enabled immediately but they must
+ * wait until the guest configures SR-IOV.
+ * When powering off, their corresponding PFs will be reset and disable
+ * VFs.
+ */
+ if (!pci_is_vf(pci_dev)) {
+ pci_set_enabled(pci_dev, state);
+ }
+}
+
uint16_t pci_requester_id(PCIDevice *dev);
/* DMA access functions */
diff --git a/include/hw/pci/pcie_sriov.h b/include/hw/pci/pcie_sriov.h
index 450cbef6c201..70649236c18a 100644
--- a/include/hw/pci/pcie_sriov.h
+++ b/include/hw/pci/pcie_sriov.h
@@ -18,7 +18,6 @@
typedef struct PCIESriovPF {
uint16_t num_vfs; /* Number of virtual functions created */
uint8_t vf_bar_type[PCI_NUM_REGIONS]; /* Store type for each VF bar */
- const char *vfname; /* Reference to the device type used for the VFs */
PCIDevice **vf; /* Pointer to an array of num_vfs VF devices */
} PCIESriovPF;
@@ -27,10 +26,11 @@ typedef struct PCIESriovVF {
uint16_t vf_number; /* Logical VF number of this function */
} PCIESriovVF;
-void pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
+bool pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
const char *vfname, uint16_t vf_dev_id,
uint16_t init_vfs, uint16_t total_vfs,
- uint16_t vf_offset, uint16_t vf_stride);
+ uint16_t vf_offset, uint16_t vf_stride,
+ Error **errp);
void pcie_sriov_pf_exit(PCIDevice *dev);
/* Set up a VF bar in the SR/IOV bar area */
diff --git a/hw/net/igb.c b/hw/net/igb.c
index b92bba402e0d..b6ca2f1b8aee 100644
--- a/hw/net/igb.c
+++ b/hw/net/igb.c
@@ -446,9 +446,16 @@ static void igb_pci_realize(PCIDevice *pci_dev, Error **errp)
pcie_ari_init(pci_dev, 0x150);
- pcie_sriov_pf_init(pci_dev, IGB_CAP_SRIOV_OFFSET, TYPE_IGBVF,
- IGB_82576_VF_DEV_ID, IGB_MAX_VF_FUNCTIONS, IGB_MAX_VF_FUNCTIONS,
- IGB_VF_OFFSET, IGB_VF_STRIDE);
+ if (!pcie_sriov_pf_init(pci_dev, IGB_CAP_SRIOV_OFFSET,
+ TYPE_IGBVF, IGB_82576_VF_DEV_ID,
+ IGB_MAX_VF_FUNCTIONS, IGB_MAX_VF_FUNCTIONS,
+ IGB_VF_OFFSET, IGB_VF_STRIDE,
+ errp)) {
+ pcie_cap_exit(pci_dev);
+ igb_cleanup_msix(s);
+ msi_uninit(pci_dev);
+ return;
+ }
pcie_sriov_pf_init_vf_bar(pci_dev, IGBVF_MMIO_BAR_IDX,
PCI_BASE_ADDRESS_MEM_TYPE_64 | PCI_BASE_ADDRESS_MEM_PREFETCH,
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index c6d4f61a47f9..e86ea2e7ce57 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8271,7 +8271,8 @@ out:
return pow2ceil(bar_size);
}
-static void nvme_init_sriov(NvmeCtrl *n, PCIDevice *pci_dev, uint16_t offset)
+static bool nvme_init_sriov(NvmeCtrl *n, PCIDevice *pci_dev, uint16_t offset,
+ Error **errp)
{
uint16_t vf_dev_id = n->params.use_intel_id ?
PCI_DEVICE_ID_INTEL_NVME : PCI_DEVICE_ID_REDHAT_NVME;
@@ -8280,12 +8281,17 @@ static void nvme_init_sriov(NvmeCtrl *n, PCIDevice *pci_dev, uint16_t offset)
le16_to_cpu(cap->vifrsm),
NULL, NULL);
- pcie_sriov_pf_init(pci_dev, offset, "nvme", vf_dev_id,
- n->params.sriov_max_vfs, n->params.sriov_max_vfs,
- NVME_VF_OFFSET, NVME_VF_STRIDE);
+ if (!pcie_sriov_pf_init(pci_dev, offset, "nvme", vf_dev_id,
+ n->params.sriov_max_vfs, n->params.sriov_max_vfs,
+ NVME_VF_OFFSET, NVME_VF_STRIDE,
+ errp)) {
+ return false;
+ }
pcie_sriov_pf_init_vf_bar(pci_dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY |
PCI_BASE_ADDRESS_MEM_TYPE_64, bar_size);
+
+ return true;
}
static int nvme_add_pm_capability(PCIDevice *pci_dev, uint8_t offset)
@@ -8410,6 +8416,12 @@ static bool nvme_init_pci(NvmeCtrl *n, PCIDevice *pci_dev, Error **errp)
return false;
}
+ if (!pci_is_vf(pci_dev) && n->params.sriov_max_vfs &&
+ !nvme_init_sriov(n, pci_dev, 0x120, errp)) {
+ msix_uninit(pci_dev, &n->bar0, &n->bar0);
+ return false;
+ }
+
nvme_update_msixcap_ts(pci_dev, n->conf_msix_qsize);
pcie_cap_deverr_init(pci_dev);
@@ -8439,10 +8451,6 @@ static bool nvme_init_pci(NvmeCtrl *n, PCIDevice *pci_dev, Error **errp)
nvme_init_pmr(n, pci_dev);
}
- if (!pci_is_vf(pci_dev) && n->params.sriov_max_vfs) {
- nvme_init_sriov(n, pci_dev, 0x120);
- }
-
return true;
}
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index b532888e8f6c..5c0050e1786a 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2895,7 +2895,7 @@ void pci_set_enabled(PCIDevice *d, bool state)
memory_region_set_enabled(&d->bus_master_enable_region,
(pci_get_word(d->config + PCI_COMMAND)
& PCI_COMMAND_MASTER) && d->enabled);
- if (!d->enabled) {
+ if (d->qdev.realized) {
pci_device_reset(d);
}
}
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 499becd5273f..4bffe6c97f66 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci/pcie_sriov.c
@@ -20,15 +20,25 @@
#include "qapi/error.h"
#include "trace.h"
-static PCIDevice *register_vf(PCIDevice *pf, int devfn,
- const char *name, uint16_t vf_num);
-static void unregister_vfs(PCIDevice *dev);
+static void unparent_vfs(PCIDevice *dev, uint16_t total_vfs)
+{
+ for (uint16_t i = 0; i < total_vfs; i++) {
+ PCIDevice *vf = dev->exp.sriov_pf.vf[i];
+ object_unparent(OBJECT(vf));
+ object_unref(OBJECT(vf));
+ }
+ g_free(dev->exp.sriov_pf.vf);
+ dev->exp.sriov_pf.vf = NULL;
+}
-void pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
+bool pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
const char *vfname, uint16_t vf_dev_id,
uint16_t init_vfs, uint16_t total_vfs,
- uint16_t vf_offset, uint16_t vf_stride)
+ uint16_t vf_offset, uint16_t vf_stride,
+ Error **errp)
{
+ BusState *bus = qdev_get_parent_bus(&dev->qdev);
+ int32_t devfn = dev->devfn + vf_offset;
uint8_t *cfg = dev->config + offset;
uint8_t *wmask;
@@ -36,7 +46,6 @@ void pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
offset, PCI_EXT_CAP_SRIOV_SIZEOF);
dev->exp.sriov_cap = offset;
dev->exp.sriov_pf.num_vfs = 0;
- dev->exp.sriov_pf.vfname = g_strdup(vfname);
dev->exp.sriov_pf.vf = NULL;
pci_set_word(cfg + PCI_SRIOV_VF_OFFSET, vf_offset);
@@ -69,13 +78,35 @@ void pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
pci_set_word(wmask + PCI_SRIOV_SYS_PGSIZE, 0x553);
qdev_prop_set_bit(&dev->qdev, "multifunction", true);
+
+ dev->exp.sriov_pf.vf = g_new(PCIDevice *, total_vfs);
+
+ for (uint16_t i = 0; i < total_vfs; i++) {
+ PCIDevice *vf = pci_new(devfn, vfname);
+ vf->exp.sriov_vf.pf = dev;
+ vf->exp.sriov_vf.vf_number = i;
+
+ if (!qdev_realize(&vf->qdev, bus, errp)) {
+ unparent_vfs(dev, i);
+ return false;
+ }
+
+ /* set vid/did according to sr/iov spec - they are not used */
+ pci_config_set_vendor_id(vf->config, 0xffff);
+ pci_config_set_device_id(vf->config, 0xffff);
+
+ dev->exp.sriov_pf.vf[i] = vf;
+ devfn += vf_stride;
+ }
+
+ return true;
}
void pcie_sriov_pf_exit(PCIDevice *dev)
{
- unregister_vfs(dev);
- g_free((char *)dev->exp.sriov_pf.vfname);
- dev->exp.sriov_pf.vfname = NULL;
+ uint8_t *cfg = dev->config + dev->exp.sriov_cap;
+
+ unparent_vfs(dev, pci_get_word(cfg + PCI_SRIOV_TOTAL_VF));
}
void pcie_sriov_pf_init_vf_bar(PCIDevice *dev, int region_num,
@@ -141,38 +172,11 @@ void pcie_sriov_vf_register_bar(PCIDevice *dev, int region_num,
}
}
-static PCIDevice *register_vf(PCIDevice *pf, int devfn, const char *name,
- uint16_t vf_num)
-{
- PCIDevice *dev = pci_new(devfn, name);
- dev->exp.sriov_vf.pf = pf;
- dev->exp.sriov_vf.vf_number = vf_num;
- PCIBus *bus = pci_get_bus(pf);
- Error *local_err = NULL;
-
- qdev_realize(&dev->qdev, &bus->qbus, &local_err);
- if (local_err) {
- error_report_err(local_err);
- return NULL;
- }
-
- /* set vid/did according to sr/iov spec - they are not used */
- pci_config_set_vendor_id(dev->config, 0xffff);
- pci_config_set_device_id(dev->config, 0xffff);
-
- return dev;
-}
-
static void register_vfs(PCIDevice *dev)
{
uint16_t num_vfs;
uint16_t i;
uint16_t sriov_cap = dev->exp.sriov_cap;
- uint16_t vf_offset =
- pci_get_word(dev->config + sriov_cap + PCI_SRIOV_VF_OFFSET);
- uint16_t vf_stride =
- pci_get_word(dev->config + sriov_cap + PCI_SRIOV_VF_STRIDE);
- int32_t devfn = dev->devfn + vf_offset;
assert(sriov_cap > 0);
num_vfs = pci_get_word(dev->config + sriov_cap + PCI_SRIOV_NUM_VF);
@@ -180,18 +184,10 @@ static void register_vfs(PCIDevice *dev)
return;
}
- dev->exp.sriov_pf.vf = g_new(PCIDevice *, num_vfs);
-
trace_sriov_register_vfs(dev->name, PCI_SLOT(dev->devfn),
PCI_FUNC(dev->devfn), num_vfs);
for (i = 0; i < num_vfs; i++) {
- dev->exp.sriov_pf.vf[i] = register_vf(dev, devfn,
- dev->exp.sriov_pf.vfname, i);
- if (!dev->exp.sriov_pf.vf[i]) {
- num_vfs = i;
- break;
- }
- devfn += vf_stride;
+ pci_set_enabled(dev->exp.sriov_pf.vf[i], true);
}
dev->exp.sriov_pf.num_vfs = num_vfs;
}
@@ -204,12 +200,8 @@ static void unregister_vfs(PCIDevice *dev)
trace_sriov_unregister_vfs(dev->name, PCI_SLOT(dev->devfn),
PCI_FUNC(dev->devfn), num_vfs);
for (i = 0; i < num_vfs; i++) {
- PCIDevice *vf = dev->exp.sriov_pf.vf[i];
- object_unparent(OBJECT(vf));
- object_unref(OBJECT(vf));
+ pci_set_enabled(dev->exp.sriov_pf.vf[i], false);
}
- g_free(dev->exp.sriov_pf.vf);
- dev->exp.sriov_pf.vf = NULL;
dev->exp.sriov_pf.num_vfs = 0;
}
@@ -231,14 +223,10 @@ void pcie_sriov_config_write(PCIDevice *dev, uint32_t address,
PCI_FUNC(dev->devfn), off, val, len);
if (range_covers_byte(off, len, PCI_SRIOV_CTRL)) {
- if (dev->exp.sriov_pf.num_vfs) {
- if (!(val & PCI_SRIOV_CTRL_VFE)) {
- unregister_vfs(dev);
- }
+ if (val & PCI_SRIOV_CTRL_VFE) {
+ register_vfs(dev);
} else {
- if (val & PCI_SRIOV_CTRL_VFE) {
- register_vfs(dev);
- }
+ unregister_vfs(dev);
}
}
}
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 09/13] pcie_sriov: Release VFs failed to realize
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (7 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 08/13] pcie_sriov: Reuse SR-IOV VF device instances Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 10/13] pcie_sriov: Remove num_vfs from PCIESriovPF Akihiko Odaki
` (3 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
Release VFs failed to realize just as we do in unregister_vfs().
Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)")
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
hw/pci/pcie_sriov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 4bffe6c97f66..ac8c4013bc88 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci/pcie_sriov.c
@@ -87,6 +87,8 @@ bool pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
vf->exp.sriov_vf.vf_number = i;
if (!qdev_realize(&vf->qdev, bus, errp)) {
+ object_unparent(OBJECT(vf));
+ object_unref(vf);
unparent_vfs(dev, i);
return false;
}
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 10/13] pcie_sriov: Remove num_vfs from PCIESriovPF
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (8 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 09/13] pcie_sriov: Release VFs failed to realize Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 11/13] pcie_sriov: Register VFs after migration Akihiko Odaki
` (2 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
num_vfs is not migrated so use PCI_SRIOV_CTRL_VFE and PCI_SRIOV_NUM_VF
instead.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
include/hw/pci/pcie_sriov.h | 1 -
hw/pci/pcie_sriov.c | 38 +++++++++++++++++++++++++++-----------
hw/pci/trace-events | 2 +-
3 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/include/hw/pci/pcie_sriov.h b/include/hw/pci/pcie_sriov.h
index 70649236c18a..5148c5b77dd1 100644
--- a/include/hw/pci/pcie_sriov.h
+++ b/include/hw/pci/pcie_sriov.h
@@ -16,7 +16,6 @@
#include "hw/pci/pci.h"
typedef struct PCIESriovPF {
- uint16_t num_vfs; /* Number of virtual functions created */
uint8_t vf_bar_type[PCI_NUM_REGIONS]; /* Store type for each VF bar */
PCIDevice **vf; /* Pointer to an array of num_vfs VF devices */
} PCIESriovPF;
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index ac8c4013bc88..47028e150eac 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci/pcie_sriov.c
@@ -45,7 +45,6 @@ bool pcie_sriov_pf_init(PCIDevice *dev, uint16_t offset,
pcie_add_capability(dev, PCI_EXT_CAP_ID_SRIOV, 1,
offset, PCI_EXT_CAP_SRIOV_SIZEOF);
dev->exp.sriov_cap = offset;
- dev->exp.sriov_pf.num_vfs = 0;
dev->exp.sriov_pf.vf = NULL;
pci_set_word(cfg + PCI_SRIOV_VF_OFFSET, vf_offset);
@@ -182,29 +181,28 @@ static void register_vfs(PCIDevice *dev)
assert(sriov_cap > 0);
num_vfs = pci_get_word(dev->config + sriov_cap + PCI_SRIOV_NUM_VF);
- if (num_vfs > pci_get_word(dev->config + sriov_cap + PCI_SRIOV_TOTAL_VF)) {
- return;
- }
trace_sriov_register_vfs(dev->name, PCI_SLOT(dev->devfn),
PCI_FUNC(dev->devfn), num_vfs);
for (i = 0; i < num_vfs; i++) {
pci_set_enabled(dev->exp.sriov_pf.vf[i], true);
}
- dev->exp.sriov_pf.num_vfs = num_vfs;
+
+ pci_set_word(dev->wmask + sriov_cap + PCI_SRIOV_NUM_VF, 0);
}
static void unregister_vfs(PCIDevice *dev)
{
- uint16_t num_vfs = dev->exp.sriov_pf.num_vfs;
+ uint8_t *cfg = dev->config + dev->exp.sriov_cap;
uint16_t i;
trace_sriov_unregister_vfs(dev->name, PCI_SLOT(dev->devfn),
- PCI_FUNC(dev->devfn), num_vfs);
- for (i = 0; i < num_vfs; i++) {
+ PCI_FUNC(dev->devfn));
+ for (i = 0; i < pci_get_word(cfg + PCI_SRIOV_TOTAL_VF); i++) {
pci_set_enabled(dev->exp.sriov_pf.vf[i], false);
}
- dev->exp.sriov_pf.num_vfs = 0;
+
+ pci_set_word(dev->wmask + dev->exp.sriov_cap + PCI_SRIOV_NUM_VF, 0xffff);
}
void pcie_sriov_config_write(PCIDevice *dev, uint32_t address,
@@ -230,6 +228,17 @@ void pcie_sriov_config_write(PCIDevice *dev, uint32_t address,
} else {
unregister_vfs(dev);
}
+ } else if (range_covers_byte(off, len, PCI_SRIOV_NUM_VF)) {
+ uint8_t *cfg = dev->config + sriov_cap;
+ uint8_t *wmask = dev->wmask + sriov_cap;
+ uint16_t num_vfs = pci_get_word(cfg + PCI_SRIOV_NUM_VF);
+ uint16_t wmask_val = PCI_SRIOV_CTRL_MSE | PCI_SRIOV_CTRL_ARI;
+
+ if (num_vfs <= pci_get_word(cfg + PCI_SRIOV_TOTAL_VF)) {
+ wmask_val |= PCI_SRIOV_CTRL_VFE;
+ }
+
+ pci_set_word(wmask + PCI_SRIOV_CTRL, wmask_val);
}
}
@@ -246,6 +255,8 @@ void pcie_sriov_pf_reset(PCIDevice *dev)
unregister_vfs(dev);
pci_set_word(dev->config + sriov_cap + PCI_SRIOV_NUM_VF, 0);
+ pci_set_word(dev->wmask + sriov_cap + PCI_SRIOV_CTRL,
+ PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE | PCI_SRIOV_CTRL_ARI);
/*
* Default is to use 4K pages, software can modify it
@@ -292,7 +303,7 @@ PCIDevice *pcie_sriov_get_pf(PCIDevice *dev)
PCIDevice *pcie_sriov_get_vf_at_index(PCIDevice *dev, int n)
{
assert(!pci_is_vf(dev));
- if (n < dev->exp.sriov_pf.num_vfs) {
+ if (n < pcie_sriov_num_vfs(dev)) {
return dev->exp.sriov_pf.vf[n];
}
return NULL;
@@ -300,5 +311,10 @@ PCIDevice *pcie_sriov_get_vf_at_index(PCIDevice *dev, int n)
uint16_t pcie_sriov_num_vfs(PCIDevice *dev)
{
- return dev->exp.sriov_pf.num_vfs;
+ uint16_t sriov_cap = dev->exp.sriov_cap;
+ uint8_t *cfg = dev->config + sriov_cap;
+
+ return sriov_cap &&
+ (pci_get_word(cfg + PCI_SRIOV_CTRL) & PCI_SRIOV_CTRL_VFE) ?
+ pci_get_word(cfg + PCI_SRIOV_NUM_VF) : 0;
}
diff --git a/hw/pci/trace-events b/hw/pci/trace-events
index 19643aa8c6b0..e98f575a9d19 100644
--- a/hw/pci/trace-events
+++ b/hw/pci/trace-events
@@ -14,7 +14,7 @@ msix_write_config(char *name, bool enabled, bool masked) "dev %s enabled %d mask
# hw/pci/pcie_sriov.c
sriov_register_vfs(const char *name, int slot, int function, int num_vfs) "%s %02x:%x: creating %d vf devs"
-sriov_unregister_vfs(const char *name, int slot, int function, int num_vfs) "%s %02x:%x: Unregistering %d vf devs"
+sriov_unregister_vfs(const char *name, int slot, int function) "%s %02x:%x: Unregistering vf devs"
sriov_config_write(const char *name, int slot, int fun, uint32_t offset, uint32_t val, uint32_t len) "%s %02x:%x: sriov offset 0x%x val 0x%x len %d"
# pcie.c
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 11/13] pcie_sriov: Register VFs after migration
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (9 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 10/13] pcie_sriov: Remove num_vfs from PCIESriovPF Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 12/13] hw/pci: Use -1 as the default value for rombar Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 13/13] hw/qdev: Remove opts member Akihiko Odaki
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
pcie_sriov doesn't have code to restore its state after migration, but
igb, which uses pcie_sriov, naively claimed its migration capability.
Add code to register VFs after migration and fix igb migration.
Fixes: 3a977deebe6b ("Intrdocue igb device emulation")
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
include/hw/pci/pcie_sriov.h | 2 ++
hw/pci/pci.c | 7 +++++++
hw/pci/pcie_sriov.c | 7 +++++++
3 files changed, 16 insertions(+)
diff --git a/include/hw/pci/pcie_sriov.h b/include/hw/pci/pcie_sriov.h
index 5148c5b77dd1..c5d2d318d330 100644
--- a/include/hw/pci/pcie_sriov.h
+++ b/include/hw/pci/pcie_sriov.h
@@ -57,6 +57,8 @@ void pcie_sriov_pf_add_sup_pgsize(PCIDevice *dev, uint16_t opt_sup_pgsize);
void pcie_sriov_config_write(PCIDevice *dev, uint32_t address,
uint32_t val, int len);
+void pcie_sriov_pf_post_load(PCIDevice *dev);
+
/* Reset SR/IOV */
void pcie_sriov_pf_reset(PCIDevice *dev);
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 5c0050e1786a..4c7be5295110 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -733,10 +733,17 @@ static bool migrate_is_not_pcie(void *opaque, int version_id)
return !pci_is_express((PCIDevice *)opaque);
}
+static int pci_post_load(void *opaque, int version_id)
+{
+ pcie_sriov_pf_post_load(opaque);
+ return 0;
+}
+
const VMStateDescription vmstate_pci_device = {
.name = "PCIDevice",
.version_id = 2,
.minimum_version_id = 1,
+ .post_load = pci_post_load,
.fields = (const VMStateField[]) {
VMSTATE_INT32_POSITIVE_LE(version_id, PCIDevice),
VMSTATE_BUFFER_UNSAFE_INFO_TEST(config, PCIDevice,
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index 47028e150eac..a1cb1214af27 100644
--- a/hw/pci/pcie_sriov.c
+++ b/hw/pci/pcie_sriov.c
@@ -242,6 +242,13 @@ void pcie_sriov_config_write(PCIDevice *dev, uint32_t address,
}
}
+void pcie_sriov_pf_post_load(PCIDevice *dev)
+{
+ if (dev->exp.sriov_cap) {
+ register_vfs(dev);
+ }
+}
+
/* Reset SR/IOV */
void pcie_sriov_pf_reset(PCIDevice *dev)
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 12/13] hw/pci: Use -1 as the default value for rombar
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (10 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 11/13] pcie_sriov: Register VFs after migration Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
2024-09-13 3:44 ` [PATCH v16 13/13] hw/qdev: Remove opts member Akihiko Odaki
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
vfio_pci_size_rom() distinguishes whether rombar is explicitly set to 1
by checking dev->opts, bypassing the QOM property infrastructure.
Use -1 as the default value for rombar to tell if the user explicitly
set it to 1. The property is also converted from unsigned to signed.
-1 is signed so it is safe to give it a new meaning. The values in
[2 ^ 31, 2 ^ 32) become invalid, but nobody should have typed these
values by chance.
Suggested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
---
include/hw/pci/pci_device.h | 2 +-
hw/pci/pci.c | 2 +-
hw/vfio/pci.c | 5 ++---
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
index 1ff3ce94e25b..8fa845beee5e 100644
--- a/include/hw/pci/pci_device.h
+++ b/include/hw/pci/pci_device.h
@@ -148,7 +148,7 @@ struct PCIDevice {
uint32_t romsize;
bool has_rom;
MemoryRegion rom;
- uint32_t rom_bar;
+ int32_t rom_bar;
/* INTx routing notifier */
PCIINTxRoutingNotifier intx_routing_notifier;
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 4c7be5295110..d2eaf0c51dde 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -71,7 +71,7 @@ static Property pci_props[] = {
DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
DEFINE_PROP_UINT32("romsize", PCIDevice, romsize, UINT32_MAX),
- DEFINE_PROP_UINT32("rombar", PCIDevice, rom_bar, 1),
+ DEFINE_PROP_INT32("rombar", PCIDevice, rom_bar, -1),
DEFINE_PROP_BIT("multifunction", PCIDevice, cap_present,
QEMU_PCI_CAP_MULTIFUNCTION_BITNR, false),
DEFINE_PROP_BIT("x-pcie-lnksta-dllla", PCIDevice, cap_present,
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 2407720c3530..dc53837eac73 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1012,7 +1012,6 @@ static void vfio_pci_size_rom(VFIOPCIDevice *vdev)
{
uint32_t orig, size = cpu_to_le32((uint32_t)PCI_ROM_ADDRESS_MASK);
off_t offset = vdev->config_offset + PCI_ROM_ADDRESS;
- DeviceState *dev = DEVICE(vdev);
char *name;
int fd = vdev->vbasedev.fd;
@@ -1046,12 +1045,12 @@ static void vfio_pci_size_rom(VFIOPCIDevice *vdev)
}
if (vfio_opt_rom_in_denylist(vdev)) {
- if (dev->opts && qdict_haskey(dev->opts, "rombar")) {
+ if (vdev->pdev.rom_bar > 0) {
warn_report("Device at %s is known to cause system instability"
" issues during option rom execution",
vdev->vbasedev.name);
error_printf("Proceeding anyway since user specified"
- " non zero value for rombar\n");
+ " positive value for rombar\n");
} else {
warn_report("Rom loading for device at %s has been disabled"
" due to system instability issues",
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v16 13/13] hw/qdev: Remove opts member
2024-09-13 3:44 [PATCH v16 00/13] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
` (11 preceding siblings ...)
2024-09-13 3:44 ` [PATCH v16 12/13] hw/pci: Use -1 as the default value for rombar Akihiko Odaki
@ 2024-09-13 3:44 ` Akihiko Odaki
12 siblings, 0 replies; 28+ messages in thread
From: Akihiko Odaki @ 2024-09-13 3:44 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Michael S. Tsirkin, Marcel Apfelbaum,
Alex Williamson, Cédric Le Goater, Paolo Bonzini,
Daniel P. Berrangé, Eduardo Habkost, Sriram Yagnaraman,
Jason Wang, Keith Busch, Klaus Jensen, Markus Armbruster,
Matthew Rosato, Eric Farman
Cc: qemu-devel, qemu-block, Akihiko Odaki
It is no longer used.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
---
include/hw/qdev-core.h | 4 ----
hw/core/qdev.c | 1 -
system/qdev-monitor.c | 12 +++++++-----
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 77bfcbdf732a..a3757e6769f8 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -237,10 +237,6 @@ struct DeviceState {
* @pending_deleted_expires_ms: optional timeout for deletion events
*/
int64_t pending_deleted_expires_ms;
- /**
- * @opts: QDict of options for the device
- */
- QDict *opts;
/**
* @hotplugged: was device added after PHASE_MACHINE_READY?
*/
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index f3a996f57dee..2fc84699d432 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -706,7 +706,6 @@ static void device_finalize(Object *obj)
dev->canonical_path = NULL;
}
- qobject_unref(dev->opts);
g_free(dev->id);
}
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 6af6ef7d667f..3551989d5153 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -624,6 +624,7 @@ DeviceState *qdev_device_add_from_qdict(const QDict *opts,
char *id;
DeviceState *dev = NULL;
BusState *bus = NULL;
+ QDict *properties;
driver = qdict_get_try_str(opts, "driver");
if (!driver) {
@@ -705,13 +706,14 @@ DeviceState *qdev_device_add_from_qdict(const QDict *opts,
}
/* set properties */
- dev->opts = qdict_clone_shallow(opts);
- qdict_del(dev->opts, "driver");
- qdict_del(dev->opts, "bus");
- qdict_del(dev->opts, "id");
+ properties = qdict_clone_shallow(opts);
+ qdict_del(properties, "driver");
+ qdict_del(properties, "bus");
+ qdict_del(properties, "id");
- object_set_properties_from_keyval(&dev->parent_obj, dev->opts, from_json,
+ object_set_properties_from_keyval(&dev->parent_obj, properties, from_json,
errp);
+ qobject_unref(properties);
if (*errp) {
goto err_del_dev;
}
--
2.46.0
^ permalink raw reply related [flat|nested] 28+ messages in thread