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.
> > GIO has TLS bindings (not SASL I think?) in GIO 2.28. Currently we
> > require glib 2.12 (released 2006) on POSIX systems and glib 2.20
> > (released 2009) on Windows. That's very conservative indeed, I wouldn't
> > mind changing to a newer version.
>
> Yeah, it has some level of functionality for TLS, but I'm not sure about
> the full extent of it and whether it'd be sufficient for what we need
> in VNC for example.
Okay... I don't know much about this.
> 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.
Paolo
