[Spice-devel] Implementing channel between module at spice client and guest OS

[Alon Bar-Lev]

----- Original Message -----
> From: "Marc-André Lureau" <marcandre.lureau at gmail.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "spice-devel" <spice-devel at lists.freedesktop.org>
> Sent: Tuesday, November 19, 2013 2:50:17 PM
> Subject: Re: [Spice-devel] Implementing channel between module at spice client and guest OS
> 
> Hi
> 

Hi,

Thank you for your response.

Just a few clarification bellow.

> On Mon, Nov 18, 2013 at 7:22 PM, Alon Bar-Lev <alonbl at redhat.com> wrote:
> > Hello,
> >
> > I am trying to figure out how to implement a channel between guest OS
> > process and component at client machine. Reading the documentation I found
> > and the vd_agent code which is somewhat similar but I could not find
> > complete solution.
> >
> > Here is what I imagined....
> >
> > I define a new serial interface on qemu:
> >
> > -device virtio-serial-pci
> > -device virtserialport,chardev=myappl,name=my.application.0
> > -chardev spicevmc,id=myappl,name=myappl
> >
> > This will enable a process within guest os to access
> > /dev/virtio-ports/my.application.0
> 
> 
> If you use a spicevmc name, you'll have to modify Spice server
> (spice_server_char_device_add_interface), and implement the channel
> handling in client. This can be tedious and doesn't allow "private"
> extensions.
> 
> But recently, we added the spice "port", which is just like spicevmc,
> except that you can have "private channels" without modifiying server
> etc.
> 
> It hasn't been widely used (even less when connected to a virtio
> port), but you can try using it:
> 
> -chardev spiceport,id=spiceportfoobar,name=com.foobar -device
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=spiceportfoobar,id=channel1,name=com.foobar

Just to make sure, this will create serial device at /dev/virtio-ports/com.foobar, right?

> > At client side I would like to implement a component that interact with
> > this myappl port, I could not find a way to load shared library or similar
> > dynamic module into client in spicy usage.
> >
> 
> At client side, you can follow spicy.c example. In channel_new(), you
> want to connect to the port channel signals. When
> "notify::port-opened", you can decide to handle that channel  based on
> its "port-name".

Which is spiceportfoobar in above example, right?
And I use spice_port_write_async/spice_port_event to manage this channel, right?

> 
> > If dynamic loading of modules is possible, is there any example of how to
> > do so?
> >
> > If dynamic loading of modules is impossible, is there a plan to allow it?
> 
> There is currently no registry of channel or port handlers to be
> loaded dynamically. There is currently no plan to add it, but that
> could be added later.

Is there a reason against of having something dynamic?
I mean if such support will be submitted will it be rejected?

> 
> > Assuming there is the option to load a module.
> >
> > I could not find in vdi spec[1] description of the vdi_port interface and
> > what should I do in order to communicate with the guest.
> >
> > Provided this is possible somehow, as it is working for vd_agent... and
> > provided external modules can be loaded.
> >
> > I can guess that each 'name' in the above example myapp can be connected by
> > different implementation, is that right?
> >
> > Assuming we have channel between module running on client machine and the
> > agent running on guest machine using virtual serial, is there support for
> > transferring RS232 controls? Such as DTR/DSR to detect if the device is
> > opened at guest side and if device is opened at client side? And detect
> > disconnection?
> 
> 
> You can also redirect a serial device from qemu:
> 
> -chardev spiceport,id=spiceportfoobar,name=org.spice.spicy -serial
> chardev:spiceportfoobar
> 
> (with kernel argument "console=tty0 console=ttyS0,115200n8")

Here I lost you... I do not need the 'console'... I need a channel of following:

module -> client ----spice-protocol----> qemu --> guest --> application

so that:

module <---------------------stream-----------------------> application

My questions now are:
1. how application know if there is module on the other side?
2. how module knows if there is application on the other side?

Had this standard RS-232 I could use DTR/DSR... but maybe it is a better way... or none.

> 
> 
> > Another nice option I thought is to allow forking process at client side
> > with usock as stdin/stdout that redirected into specific spicevmc device,
> > this will ease the work of implementing such solutions, as the author of
> > the forked process may not have any spice knowledge at all, while be able
> > to participate within the solution.
> 
> That's a possibility, patches welcome.

Evaluating the options... :)

Thanks,
Alon Bar-Lev.