Re: [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU

[Marc-André Lureau]

Hi

On Tue, Sep 11, 2018 at 12:59 PM Gerd Hoffmann <address@hidden> 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