Hi On Thu, Apr 9, 2020 at 2:46 PM Coiby Xu <coiby...@gmail.com> wrote: > > > Hi, > > I'm now implementing vhost-user block device backend > https://patchew.org/QEMU/20200309100342.14921-1-coiby...@gmail.com/ > and want to use chardev to help manage vhost-user client connections > and read socket message. However there are two issues that need to be > addressed. > > Firstly, chardev isn't suitable for the case when exported drive is > run in an IOThread because for mow chardev use GSource to dispatch > socket fd events. So I have to specify which IOThread the exported > drive is using when launching vhost-user block device backend, > for example, the following syntax will be used, > > -drive file=file.img,id=disk -device > virtio-blk,drive=disk,iothread=iothread0 \ > -object > vhost-user-blk-server,node-name=disk,chardev=mon1,iothread=iothread0 \ > -object iothread,id=iothread0 \ > -chardev > socket,id=mon1,path=/tmp/vhost-user-blk_vhost.socket,server,nowait > > then iothread_get_g_main_context(IOThread *iothread) has to be called > to run the gcontext in IOThread. If we use AioContext to dispatch socket > fd events, we needn't to specify IOThread twice. Besides aio_poll is faster > than g_main_loop_run. > > Secondly, socket chardev's async read handler (set through > qemu_chr_fe_set_handlers) doesn't take the case of socket short read > into consideration. I plan to add one which will make use qio_channel_yield. > > According to > [1] Improving the QEMU Event Loop - Linux Foundation Events > http://events17.linuxfoundation.org/sites/events/files/slides/Improving%20the%20QEMU%20Event%20Loop%20-%203.pdf > > "Convert chardev GSource to aio or an equivalent source" (p.30) should have > been finished. I'm curious why the plan didn't continue. If it's desirable, > I'm going to finish the leftover work to resolve the aforementioned two > issues.
Converting all chardevs to Aio might be challenging, and doesn't bring much benefits imho. Perhaps a better approach would be to rely on a new chardev API to steal the chardev underlying fd or QIO... (mostly keeping -chardev for CLI/QMP compatibility reason - although breaking some chardev features that imho aren't compatible with all use cases, like replay, muxing, swapping etc). The chardev should probably be removed after that...