Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Feb 04, 2015 at 03:23:22PM +0100, Paolo Bonzini wrote:
> 
> 
> On 04/02/2015 15:08, Daniel P. Berrange wrote:
> >> > As long as QEMUFile remains there and GIOChannel is used only when
> >> > encryption is required, that would be an acceptable limitation.  As I
> >> > wrote above, migration is a bit special anyway.
> > I'm not sure I'd like the idea of having different codepaths for
> > the encrypted vs non-encrypted impl. it seems like a recipe for
> > increased maintainence work and inconsistent behaviour over the
> > long term. My thought was that QEMUFile would basically go
> > away entirely by the end of the conversion, or at most be dealing
> > with the data rate throttling if that didn't fit nicely into the
> > generic IO layer.
> 
> QEMUFile has a bunch of hooks for RDMA (they were also used by the
> never-upstreamed patches to speed up AF_UNIX migration with vmsplice),
> so it cannot go away:
> 
> typedef struct QEMUFileOps {
>     QEMUFilePutBufferFunc *put_buffer;
>     QEMUFileGetBufferFunc *get_buffer;
>     QEMUFileCloseFunc *close;
>     QEMUFileGetFD *get_fd;
>     QEMUFileWritevBufferFunc *writev_buffer;
>     QEMURamHookFunc *before_ram_iterate;
>     QEMURamHookFunc *after_ram_iterate;
>     QEMURamHookFunc *hook_ram_load;
>     QEMURamSaveFunc *save_page;
>     QEMUFileShutdownFunc *shut_down;
> } QEMUFileOps;
> 
> GIO doesn't provide writev either, so it's not a good match for
> non-encrypted migration, which really tries hard to do no copies in
> userspace.

Ok, maybe RDMA will still need QEMUFile, but for non-encrypted TCP
I'd hope to be able to achieve zero-copy with the new API too - it
would certainly be my intention/goal.

> > The main difference between GIO's APIs and GIOChannel is that the new
> > GIO stuff is really designed around the idea of asynchronous callbacks
> > for completion of IO.
> > 
> >   eg
> > 
> >      g_input_stream_read_async(stream, buffer, size, read_done_callback);
> > 
> >  and then when read_done_callback gets triggered you have to call
> > 
> >      g_input_stream_read_finish(stream)
> > 
> > in order to get the success/failure status of the read, and the byte
> > count. While it is quite nice for new code IME, this is probably quite
> > alot harder to refit into existing QEMU codebase.
> 
> It also supports GIOChannel's GSource model via
> GPollableInputStream/GPollableOutputStream.  The GNUTLS bindings support
> that interface too.
> 
> It also supports blocking operation, which is what migration wants.
> 
> So I think we could take a look at GIO if its TLS support is advanced
> enough for your purposes.

Ok, I'll investigate GIO a little further to see how practical a fit it
is for us.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|