Hi On Tue, Sep 11, 2018 at 12:59 PM Gerd Hoffmann <kra...@redhat.com> wrote: > > > > > $ ./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 ...
The management layer can set things up and pass fd around, avoiding socket paths etc. > > > 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. ok (slightly less convenient for command line users though) > > > 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? yes (see the related libvirt series / branch) > > > - 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? Yes I am not sure it is strictly necessary (that's why I put optionally). The helper could fork itself, for various reasons. > > > 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' ] > I wouldn't go so far as describing the command line arguments here. Or else, we will have to specify the argument type etc. Instead, I would use a list of well-known keywords, described in the specification. "vulkan" caps would mean that --enable-vulkan (without argument) is accepted and has an expected behaviour (to handle vulkan commands / rendering etc) I don't see a problem putting the list in a json array, but I don't see much benefit either doing it. > 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? I am not sure I understand the qestion. libvirt would deal with the binary capabilities like it deals with qemu capabilities. It would use the best combination of options given a domain XML and the capabilities. If the domain XML requests a feature that the backend is not able to support, it would provide a sensible error. Unknown capabilities would be ignored. > > > 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. ok > > > - vhost-user-gpu --render-node=PATH (optional) > > > > I am not sure how this should be documented. > > docs/specs/ ? ok, I suppose I can start some document and include libvir-list for discussion. -- Marc-André Lureau
