> > > $ ./vhost-user-gpu --virgl -s vgpu.sock &
> > > $ qemu...
> > > -chardev socket,id=chr,path=vgpu.sock
> > > -object vhost-user-backend,id=vug,chardev=chr
> > > -device vhost-user-vga,vhost-user=vug
> >
> > That's a bit incovenient for qemu command line users. But who runs
> > qemu this way but some developers? (others have higher-level scripts /
> > tools or libvirt)
In practice this will *allways* run over a unix socket, right?
So I'm wondering whenever it makes sense to take the chardev
indirection here ...
> I suggest the vhost-user binary (vhost-user-gpu or vhost-user-input
> etc), the default binary be in the system PATH, so that libvirt & co
> can find it. Host administrator can use update-alternative or such if
> they are other implementations. (other selections mechanisms can be
> added later)
Might make sense to place them in /usr/libexec instead.
> I thinks the vhost-user backends could have the following common
> options handling:
> - take a "--fd=FDNUM" argument, that would indicate which fd the
> socket has been passed on.
Which is what libvirt would use, right?
> - OR take a "--socket-path=PATH"
Convinient when not using libvirt, looks ok to me.
> - optionally? take a "--pid=PATH" argument, to write out the process PID
Do we need that? When libvirt forks off the process it knows the PID
without pidfile, right?
> We probably need a way to list the capabilities of the backend.:
> --dump-caps, could list known keywords, one per line? (grab, virgl,
> opengles, etc...)
Hmm, good question.
I'd tend include more information here. Such as a description of the
capability. The command line switch to enable it. Print as json, we
have support in both qemu and libvirt. Something like
[ 'name' : 'vulkan',
'help' : 'enable virgl vulkan support',
'switch' : '--enable-vulkan' ]
What would libvirt like to consume here? Would it actually be able to
use whatever it finds there? Or would libvirt look for specific known
features only, matching them with domain xml attributes?
> Other options may vary based on the backend type, for ex:
> - vhost-user-input EVDEV-PATH (required)
I'd go for "--evdev-path=/dev/input/..." syntax even for mandatory
arguments.
> - vhost-user-gpu --render-node=PATH (optional)
>
> I am not sure how this should be documented.
docs/specs/ ?
cheers,
Gerd
