* [PATCH v3] virtio_pci: avoid to request intx irq if pin is zero
@ 2022-09-30 0:09 Angus Chen
0 siblings, 0 replies; 5+ messages in thread
From: Angus Chen @ 2022-09-30 0:09 UTC (permalink / raw)
To: jasowang, mst; +Cc: virtualization, linux-kernel, Angus Chen
The background is that we use dpu in cloud computing,the arch is x86,80
cores.We will have a lots of virtio devices,like 512 or more.
When we probe about 200 virtio_blk devices,it will fail and
the stack is print as follows:
[25338.485128] virtio-pci 0000:b3:00.0: virtio_pci: leaving for legacy driver
[25338.496174] genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)
[25338.503822] CPU: 20 PID: 5431 Comm: kworker/20:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.30.1.el8.x86_64
[25338.516403] Hardware name: Inspur NF5280M5/YZMB-00882-10E, BIOS 4.1.21 08/25/2021
[25338.523881] Workqueue: events work_for_cpu_fn
[25338.528235] Call Trace:
[25338.530687] dump_stack+0x5c/0x80
[25338.534000] __setup_irq.cold.53+0x7c/0xd3
[25338.538098] request_threaded_irq+0xf5/0x160
[25338.542371] vp_find_vqs+0xc7/0x190
[25338.545866] init_vq+0x17c/0x2e0 [virtio_blk]
[25338.550223] ? ncpus_cmp_func+0x10/0x10
[25338.554061] virtblk_probe+0xe6/0x8a0 [virtio_blk]
[25338.558846] virtio_dev_probe+0x158/0x1f0
[25338.562861] really_probe+0x255/0x4a0
[25338.566524] ? __driver_attach_async_helper+0x90/0x90
[25338.571567] driver_probe_device+0x49/0xc0
[25338.575660] bus_for_each_drv+0x79/0xc0
[25338.579499] __device_attach+0xdc/0x160
[25338.583337] bus_probe_device+0x9d/0xb0
[25338.587167] device_add+0x418/0x780
[25338.590654] register_virtio_device+0x9e/0xe0
[25338.595011] virtio_pci_probe+0xb3/0x140
[25338.598941] local_pci_probe+0x41/0x90
[25338.602689] work_for_cpu_fn+0x16/0x20
[25338.606443] process_one_work+0x1a7/0x360
[25338.610456] ? create_worker+0x1a0/0x1a0
[25338.614381] worker_thread+0x1cf/0x390
[25338.618132] ? create_worker+0x1a0/0x1a0
[25338.622051] kthread+0x116/0x130
[25338.625283] ? kthread_flush_work_fn+0x10/0x10
[25338.629731] ret_from_fork+0x1f/0x40
[25338.633395] virtio_blk: probe of virtio418 failed with error -16
The log :
"genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)"
was print because of the irq 0 is used by timer exclusive,and when
vp_find_vqs call vp_find_vqs_msix and return false twice for
whatever reason,then it will call vp_find_vqs_intx for the last try.
Because vp_dev->pci_dev->irq is zero,so it will be request irq 0 with
flag IRQF_SHARED,we will get a backtrace like above.
According to PCI spec about "Interrupt Pin" Register (Offset 3Dh):
"The Interrupt Pin register is a read-only register that identifies the
legacy interrupt Message(s) the Function uses. Valid values are 01h, 02h,
03h, and 04h that map to legacy interrupt Messages for INTA,
INTB, INTC, and INTD respectively. A value of 00h indicates that the
Function uses no legacy interrupt Message(s)."
So if vp_dev->pci_dev->pin is zero, we should not request legacy
interrupt.
Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
---
v3:
- add quotes of PCI spec
- Move the judgment from vp_find_vqs_intx to vp_find_vqs
v2:
- Decide whether to request an intx interrupt by pin instead of irq
- suggested by mst
v1:https://lore.kernel.org/virtualization/20220928000228-mutt-send-email-mst@kernel.org/T/#u
drivers/virtio/virtio_pci_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index ad258a9d3b9f..44a839127f2b 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -409,6 +409,9 @@ int vp_find_vqs(struct virtio_device *vdev, unsigned int nvqs,
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, false, ctx, desc);
if (!err)
return 0;
+ /* Is there an interrupt pin? If not give up. */
+ if (!(to_vp_device(vdev)->pci_dev->pin))
+ return err;
/* Finally fall back to regular interrupts. */
return vp_find_vqs_intx(vdev, nvqs, vqs, callbacks, names, ctx);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* RE: [PATCH v3] virtio_pci: avoid to request intx irq if pin is zero
2022-09-29 2:30 ` Jason Wang
(?)
@ 2022-10-05 2:20 ` Angus Chen
-1 siblings, 0 replies; 5+ messages in thread
From: Angus Chen @ 2022-10-05 2:20 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, virtualization, linux-kernel
> On Wed, Sep 28, 2022 at 6:47 PM Angus Chen <angus.chen@jaguarmicro.com>
> wrote:
> >
> > The background is that we use dpu in cloud computing,the arch is x86,80
> > cores.We will have a lots of virtio devices,like 512 or more.
> > When we probe about 200 virtio_blk devices,it will fail and
> > the stack is print as follows:
>
> Not for this patch, but I wonder if it's time to introduce per cpu
> virtio interrupts instead of per device ones? This may help in this
> case.
This patch is just prevent the device
which have no intx support to request INTX.
It can be occur when msix is out of memory or out of irq
Capability etc.
So could you pls help to review this patch first?
Thank you.
>
> Thanks
>
> >
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3] virtio_pci: avoid to request intx irq if pin is zero
2022-09-28 10:46 Angus Chen
@ 2022-09-29 2:30 ` Jason Wang
0 siblings, 0 replies; 5+ messages in thread
From: Jason Wang @ 2022-09-29 2:30 UTC (permalink / raw)
To: Angus Chen; +Cc: mst, virtualization, linux-kernel
On Wed, Sep 28, 2022 at 6:47 PM Angus Chen <angus.chen@jaguarmicro.com> wrote:
>
> The background is that we use dpu in cloud computing,the arch is x86,80
> cores.We will have a lots of virtio devices,like 512 or more.
> When we probe about 200 virtio_blk devices,it will fail and
> the stack is print as follows:
Not for this patch, but I wonder if it's time to introduce per cpu
virtio interrupts instead of per device ones? This may help in this
case.
Thanks
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3] virtio_pci: avoid to request intx irq if pin is zero
@ 2022-09-29 2:30 ` Jason Wang
0 siblings, 0 replies; 5+ messages in thread
From: Jason Wang @ 2022-09-29 2:30 UTC (permalink / raw)
To: Angus Chen; +Cc: virtualization, linux-kernel, mst
On Wed, Sep 28, 2022 at 6:47 PM Angus Chen <angus.chen@jaguarmicro.com> wrote:
>
> The background is that we use dpu in cloud computing,the arch is x86,80
> cores.We will have a lots of virtio devices,like 512 or more.
> When we probe about 200 virtio_blk devices,it will fail and
> the stack is print as follows:
Not for this patch, but I wonder if it's time to introduce per cpu
virtio interrupts instead of per device ones? This may help in this
case.
Thanks
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v3] virtio_pci: avoid to request intx irq if pin is zero
@ 2022-09-28 10:46 Angus Chen
2022-09-29 2:30 ` Jason Wang
0 siblings, 1 reply; 5+ messages in thread
From: Angus Chen @ 2022-09-28 10:46 UTC (permalink / raw)
To: jasowang, mst; +Cc: virtualization, linux-kernel, Angus Chen
The background is that we use dpu in cloud computing,the arch is x86,80
cores.We will have a lots of virtio devices,like 512 or more.
When we probe about 200 virtio_blk devices,it will fail and
the stack is print as follows:
[25338.485128] virtio-pci 0000:b3:00.0: virtio_pci: leaving for legacy driver
[25338.496174] genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)
[25338.503822] CPU: 20 PID: 5431 Comm: kworker/20:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.30.1.el8.x86_64
[25338.516403] Hardware name: Inspur NF5280M5/YZMB-00882-10E, BIOS 4.1.21 08/25/2021
[25338.523881] Workqueue: events work_for_cpu_fn
[25338.528235] Call Trace:
[25338.530687] dump_stack+0x5c/0x80
[25338.534000] __setup_irq.cold.53+0x7c/0xd3
[25338.538098] request_threaded_irq+0xf5/0x160
[25338.542371] vp_find_vqs+0xc7/0x190
[25338.545866] init_vq+0x17c/0x2e0 [virtio_blk]
[25338.550223] ? ncpus_cmp_func+0x10/0x10
[25338.554061] virtblk_probe+0xe6/0x8a0 [virtio_blk]
[25338.558846] virtio_dev_probe+0x158/0x1f0
[25338.562861] really_probe+0x255/0x4a0
[25338.566524] ? __driver_attach_async_helper+0x90/0x90
[25338.571567] driver_probe_device+0x49/0xc0
[25338.575660] bus_for_each_drv+0x79/0xc0
[25338.579499] __device_attach+0xdc/0x160
[25338.583337] bus_probe_device+0x9d/0xb0
[25338.587167] device_add+0x418/0x780
[25338.590654] register_virtio_device+0x9e/0xe0
[25338.595011] virtio_pci_probe+0xb3/0x140
[25338.598941] local_pci_probe+0x41/0x90
[25338.602689] work_for_cpu_fn+0x16/0x20
[25338.606443] process_one_work+0x1a7/0x360
[25338.610456] ? create_worker+0x1a0/0x1a0
[25338.614381] worker_thread+0x1cf/0x390
[25338.618132] ? create_worker+0x1a0/0x1a0
[25338.622051] kthread+0x116/0x130
[25338.625283] ? kthread_flush_work_fn+0x10/0x10
[25338.629731] ret_from_fork+0x1f/0x40
[25338.633395] virtio_blk: probe of virtio418 failed with error -16
The log :
"genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)"
was print because of the irq 0 is used by timer exclusive,and when
vp_find_vqs call vp_find_vqs_msix and return false twice for
whatever reason,then it will call vp_find_vqs_intx for the last try.
Because vp_dev->pci_dev->irq is zero,so it will be request irq 0 with
flag IRQF_SHARED,we will get a backtrace like above.
According to PCI spec about "Interrupt Pin" Register (Offset 3Dh):
"The Interrupt Pin register is a read-only register that identifies the
legacy interrupt Message(s) the Function uses. Valid values are 01h, 02h,
03h, and 04h that map to legacy interrupt Messages for INTA,
INTB, INTC, and INTD respectively. A value of 00h indicates that the
Function uses no legacy interrupt Message(s)."
So if vp_dev->pci_dev->pin is zero, we should not request legacy
interrupt.
Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
---
v3:
- add quotes of PCI spec
- Move the judgment from vp_find_vqs_intx to vp_find_vqs
v2:
- Decide whether to request an intx interrupt by pin instead of irq
- suggested by mst
v1:https://lore.kernel.org/virtualization/20220928000228-mutt-send-email-mst@kernel.org/T/#u
drivers/virtio/virtio_pci_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index ad258a9d3b9f..44a839127f2b 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -409,6 +409,9 @@ int vp_find_vqs(struct virtio_device *vdev, unsigned int nvqs,
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, false, ctx, desc);
if (!err)
return 0;
+ /* Is there an interrupt pin? If not give up. */
+ if (!(to_vp_device(vdev)->pci_dev->pin))
+ return err;
/* Finally fall back to regular interrupts. */
return vp_find_vqs_intx(vdev, nvqs, vqs, callbacks, names, ctx);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-10-05 2:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-30 0:09 [PATCH v3] virtio_pci: avoid to request intx irq if pin is zero Angus Chen
-- strict thread matches above, loose matches on Subject: below --
2022-09-28 10:46 Angus Chen
2022-09-29 2:30 ` Jason Wang
2022-09-29 2:30 ` Jason Wang
2022-10-05 2:20 ` Angus Chen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.