On Thu, Feb 20, 2020 at 12:16:06PM +0100, Kristof Provost wrote:
K> On 19 Feb 2020, at 23:48, Gleb Smirnoff wrote:
K> > On Tue, Feb 18, 2020 at 10:08:50PM +0100, Kristof Provost wrote:
K> > K> So I suspect our call stack is something like virtqueue_intr() ->
K> > K> vtnet_rx_vq_intr() -> vtnet_rxq_eof() -> vtnet_rxq_input() ->
K> > K> ether_input().
K> > K> I don’t see anything entering epoch in that path, which presumably
K> > explains
K> > K> the panic, but I still don’t understand why my bhyve current vm
K> > doesn’t
K> > K> panic in the same way.
K> >
K> > On bhyve we enter it through interrupt handler, and this is where we
K> > enter the epoch. Does RISC-V has interrupt handling by the MI code
K> > in sys/kern/kern_intr.c as other platforms?
K> >
K> It does, yes, but that was the hint I needed. I didn’t know that we entered
K> net_epoch automagically based on the interrupt type.
K>
K> The difference between the two is that Bhyve uses virtio_pci, and in my
K> qemu case we run through the virtio_mmio path. In that path we always set
K> INTR_TYPE_MISC, so we never set INTR_TYPE_NET, even for if_vtnet, so we
K> never entered epoch.
K>
K> This is the correct fix:
K>
K> diff --git a/sys/dev/virtio/mmio/virtio_mmio.c
K> b/sys/dev/virtio/mmio/virtio_mmio.c
K> index 95eb8647052..ccafe326868 100644
K> --- a/sys/dev/virtio/mmio/virtio_mmio.c
K> +++ b/sys/dev/virtio/mmio/virtio_mmio.c
K> @@ -196,7 +196,7 @@ vtmmio_setup_intr(device_t dev, enum intr_type type)
K> return (ENXIO);
K> }
K>
K> - if (bus_setup_intr(dev, sc->res[1], INTR_TYPE_MISC |
INTR_MPSAFE,
K> + if (bus_setup_intr(dev, sc->res[1], type | INTR_MPSAFE,
K> NULL, vtmmio_vq_intr, sc, &sc->ih)) {
K> device_printf(dev, "Can't setup the interrupt\n");
K> return (ENXIO);
Thanks a lot for the fix, Kristof!
--
Gleb Smirnoff
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
