[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU
Date: Tue, 11 Sep 2018 13:16:22 +0400


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

"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.


> > - 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]