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

[Paolo Bonzini <pbonzini@redhat.com>]

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