Hey guys,
I tried to start the vhost-device-rng daemon with QEMU v8.1.0 when I
noticed that upon startup QEMU crashes [1]. The last known good
version is v7.2.0. A bisect session between the two tags yielded this
commit [2]. In that patch the hunk that starts at line 1176 adds a
call to virtio_pci_set_guest_notifier() with a second parameter of
VIRTIO_CONFIG_IRQ_IDX, which is -1. That call trickles down to
function vhost_user_get_vq_index() [3] where the assert is generated.
I am guessing that all the pci based vhost-devices would be affected
by this change, hence this email. Has anyone seen this when using a
version of QEMU that is higher than v7.2.0?
To reproduce, start the vhost-device-rng with:
$ ./vhost-device-rng --socket-path=$(PATH_TO_SOCKET)/rng.sock -c 1 -m
512 -p 1000
And in another shell start qemu v8.1.0 with something that looks like
this[4], with line 7 to 10 being the most important. Here I'm using
RNG but I suppose any of the vhost-devices would be affected by this.
I'll wait to hear back from you guys before I make a fool of myself on
the QEMU failing list.
Thanks,
Mathieu
[1]. https://pastebin.linaro.org/view/4d39b814
[2]. 1680542862ed virtio-pci: add support for configure interrupt
[3]. https://github.com/qemu/qemu/blob/v8.0.0/hw/virtio/vhost-user.c#L2152
[4]. https://pastebin.linaro.org/view/a15db9b0
Hello,
Now that irqfd support (backend to guest interrupt) is already merged, this
series solves the other part of the problem, i.e. ioeventfd (guest to
backend interrupt).
More details inside the commits.
Arnd reported few issues with the ioctl macro usage and argument's layout, fixed
them for irqfd too, which was added recently.
--
Viresh
V3->V4:
- Use __u64 for indirect pointers in an ioctl command's arguments.
- Use u64_to_user_ptr() in kernel driver to access the same.
- Use _IOW() macro instead of the internal one: _IOC().
V2->V3:
- Remove explicit barriers and depend on spin lock instead to take care of it.
- Move check for empty ioeventfds list to privcmd_ioeventfd_deassign(), which
could earlier call ioreq_free() even when the list wasn't empty and so we
returned without printing a warning in v1 earlier. V2 implemented it
incorrectly.
V1->V2:
- Increment irq_info refcnt only for valid info.
- Use u64 type for addr.
- Add comments for use of barriers.
- Use spin lock instead of mutex as we need to use them in irq handler.
- Add a warning when kioreq is getting freed and ioeventfds list isn't empty.
- Use struct_size().
- Validate number of vcpus as well.
Viresh Kumar (4):
xen: Make struct privcmd_irqfd's layout architecture independent
xen: irqfd: Use _IOW instead of the internal _IOC() macro
xen: evtchn: Allow shared registration of IRQ handers
xen: privcmd: Add support for ioeventfd
drivers/xen/Kconfig | 8 +-
drivers/xen/events/events_base.c | 3 +-
drivers/xen/evtchn.c | 2 +-
drivers/xen/privcmd.c | 407 +++++++++++++++++++++++++++++-
include/uapi/xen/privcmd.h | 22 +-
include/xen/interface/hvm/ioreq.h | 51 ++++
6 files changed, 482 insertions(+), 11 deletions(-)
create mode 100644 include/xen/interface/hvm/ioreq.h
--
2.31.1.272.g89b43f80a514
Hello,
Now that irqfd support (backend to guest interrupt) is already merged, this
series solves the other part of the problem, i.e. ioeventfd (guest to backend
interrupt).
More details inside the commits.
--
Viresh
V2->V3:
- Remove explicit barriers and depend on spin lock instead to take care of it.
- Move check for empty ioeventfds list to privcmd_ioeventfd_deassign(), which
could earlier call ioreq_free() even when the list wasn't empty and so we
returned without printing a warning in v1 earlier. V2 implemented it
incorrectly.
V1->V2:
- Increment irq_info refcnt only for valid info.
- Use u64 type for addr.
- Add comments for use of barriers.
- Use spin lock instead of mutex as we need to use them in irq handler.
- Add a warning when kioreq is getting freed and ioeventfds list isn't empty.
- Use struct_size().
- Validate number of vcpus as well.
Viresh Kumar (2):
xen: evtchn: Allow shared registration of IRQ handers
xen: privcmd: Add support for ioeventfd
drivers/xen/Kconfig | 8 +-
drivers/xen/events/events_base.c | 3 +-
drivers/xen/evtchn.c | 2 +-
drivers/xen/privcmd.c | 405 +++++++++++++++++++++++++++++-
include/uapi/xen/privcmd.h | 18 ++
include/xen/interface/hvm/ioreq.h | 51 ++++
6 files changed, 479 insertions(+), 8 deletions(-)
create mode 100644 include/xen/interface/hvm/ioreq.h
--
2.31.1.272.g89b43f80a514
Hello,
Now that irqfd support (backend to guest interrupt) is already merged, this
series solves the other part of the problem, i.e. ioeventfd (guest to backend
interrupt).
More details inside the commits.
--
Viresh
Viresh Kumar (2):
xen: evtchn: Allow shared registration of IRQ handers
xen: privcmd: Add support for ioeventfd
drivers/xen/Kconfig | 8 +-
drivers/xen/events/events_base.c | 1 +
drivers/xen/evtchn.c | 2 +-
drivers/xen/privcmd.c | 385 +++++++++++++++++++++++++++++-
include/uapi/xen/privcmd.h | 18 ++
include/xen/interface/hvm/ioreq.h | 51 ++++
6 files changed, 458 insertions(+), 7 deletions(-)
create mode 100644 include/xen/interface/hvm/ioreq.h
--
2.31.1.272.g89b43f80a514
Hello,
Now that irqfd support (backend to guest interrupt) is already merged, this
series solves the other part of the problem, i.e. ioeventfd (guest to backend
interrupt).
More details inside the commits.
--
Viresh
V1->V2:
- Increment irq_info refcnt only for valid info.
- Use u64 type for addr.
- Add comments for use of barriers.
- Use spin lock instead of mutex as we need to use them in irq handler.
- Add a warning when kioreq is getting freed and ioeventfds list isn't empty.
- Use struct_size().
- Validate number of vcpus as well.
Viresh Kumar (2):
xen: evtchn: Allow shared registration of IRQ handers
xen: privcmd: Add support for ioeventfd
drivers/xen/Kconfig | 8 +-
drivers/xen/events/events_base.c | 3 +-
drivers/xen/evtchn.c | 2 +-
drivers/xen/privcmd.c | 398 +++++++++++++++++++++++++++++-
include/uapi/xen/privcmd.h | 18 ++
include/xen/interface/hvm/ioreq.h | 51 ++++
6 files changed, 472 insertions(+), 8 deletions(-)
create mode 100644 include/xen/interface/hvm/ioreq.h
--
2.31.1.272.g89b43f80a514