Re: Does QEMU support raising irq in thread created by device?

[Peter Maydell]

On Wed, 21 Apr 2021 at 14:15, <alan.gu@vicoretek.com> wrote:
> I’m building a device with QEMU. In realization of the device, I
> created a thread with qemu_thread_create. The thread is a dead loop
> blocking at reading a socket. If it gets something from the socket,
> the thread will raise irq with qemu_set_irq.
>
> When I run the program, sometimes I get
>
> Bail out! ERROR:../accel/tcg/tcg-cpus.c:69:tcg_cpus_handle_interrupt: 
> assertion failed: (qemu_mutex_iothread_locked())

This is because you've broken QEMU's rules about what APIs
are valid to call without locking. Just calling qemu_set_irq() from
a different thread without trying to take any lock is going to result
in race conditions and crashes. (If you stick to not creating
new threads, you don't notice the locking requirements so much,
because most of QEMU's code and especially its device models gets
called with the necessary lock already held.)

More generally, I would be wary of a design for a modification
to QEMU that starts with "create a random new thread". This is
complicated and easy to get wrong; only a few parts of QEMU
need to create new threads. So it's always worth looking for whether
there's a different approach that doesn't involve new threads.

> I also searched other instances of references of qemu_thread_create.
> none of the created threads manipulates irq.
>
> So I’m wandering is this problem because QEMU does not support
> qemu_set_irq in a thread that is neither QEMU mainloop or vcpu?
>
> Is there a better way in QEMU to get the work done, probably without creating 
> a thread?

You don't really say what work you're trying to do in much detail,
but if what you need is "do some work when I can read from a socket"
then what you want to do is probably going to involve using the
qemu_set_fd_handler() function, which arranges for the file descriptor
to be added to the set of fds that QEMU's main event loop monitors,
and then you can get a callback in the correct thread context when
the fd is readable or writeable.

Depending on what you're doing, it might also be useful to consider
the chardev APIs, which abstract out "this device can talk to some
kind of read-and-write backend, which might be a socket, or a file,
or a TTY, or ...". That way you don't need to deal with the specifics
of sockets, and your device model is more flexible. This is what all
our UART devices do, for example.

thanks
-- PMM