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