On Tue, 17 Sept 2024 at 13:32, Marc-André Lureau <marcandre.lur...@redhat.com> wrote: > > Hi Roman > > On Fri, Sep 13, 2024 at 8:37 PM Roman Penyaev <r.peni...@gmail.com> wrote: > > > > This patch implements multiplexing capability of several backend > > devices, which opens up an opportunity to use a single frontend > > device on the guest, which can be manipulated from several > > backend devices. > > > > The idea of the change is trivial: keep list of backend devices > > (up to 4), init them on demand and forward data buffer back and > > forth. > > > > The following is QEMU command line example: > > > > -chardev socket,path=/tmp/sock,server=on,wait=off,id=sock0 \ > > -chardev vc,id=vc0 \ > > -chardev mux,id=mux0,chardev=vc0,,sock0 \ > > -device virtconsole,chardev=mux0 \ > > -vnc 0.0.0.0:0 > > > > Which creates 2 backend devices: text virtual console (`vc0`) > > and a socket (`sock0`) connected to the single virtio hvc > > console with the multiplexer (`mux0`) help. `vc0` renders > > text to an image, which can be shared over the VNC protocol. > > `sock0` is a socket backend which provides biderectional > > communication to the virtio hvc console. > > I think I would rather implement a new mux for this purpose, like > "mux-be" perhaps? > > "mux" has been a bit hidden (behind mux=on) for various reasons, and > is probably not at production quality level.
You get a mux by default (for serial vs HMP monitor), so I think it's pretty heavily used and tested in that sense... -- PMM