OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative)


  Hi,
 
> So, I'm about to start working on virtio-pipe (I realize the name is
> not that great since pipes are normally unidirectional, but I'm sure
> we'll have plenty of time to bikeshed on that particular aspect once
> the other bits are sorted out :)).

virtio-ipc?

> This device would be a singleton
> (there can only be one per VM),

Why?

Alex already mentioned vhost-user.  This is basically a way to emulate
virtio devices outside qemu (not sure whenever other vmms support that
too).  With vhost emulation is done in the kernel, with vhost-user
emulation is done in another process instead.  Communication with qemu
runs over a socked with messages roughly equivalent to vhost ioctls.

There is a vhost-user implementation of virtio-gpu (see
contrib/vhost-user-gpu/ in qemu git repo).  Main motivation is that a
separate process can have a much stricter sandbox (no need to have
access to network or guest disk images), which is especially useful for
a complex thing like 3D rendering.

So one possible approach for the host side implementation would be to
write the virtio protocol parser as support library, then implement the
host applications (i.e. the host wayland proxy) as vhost-user process
using that library.

That would not work well with the singleton device approach though.

A vhost-user approach would allow for multiple vmms sharing the
implementation.  It would allow to easily pick a language other
than C (mostly relevant for qemu, crosvm isn't C anyway ...).

> * manage a central UUID <-> 'struct file' map that allows virtio-pipe
>   to convert FDs to UUIDs, pass UUIDs through a pipe and convert those
>   UUIDs back to FDs on the other end
>   - we need to expose an API to let each subsystem register/unregister
>     their UUID <-> FD mapping (subsystems are responsible for the UUID
>     creation/negotiation)

Do you have a rough plan how to do that?
On the guest side?
On the host side?

cheers,
  Gerd



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]