From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ0rc-0000U3-9C for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:23:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ0rX-00086p-5o for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:23:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ0rW-00086f-UV for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:23:27 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14ENQeJ022880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 09:23:26 -0500 Message-ID: <54D22B5A.5020904@redhat.com> Date: Wed, 04 Feb 2015 15:23:22 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20150204113229.GN3032@redhat.com> <54D213E0.8090408@redhat.com> <20150204130041.GQ3032@redhat.com> <54D221BC.50008@redhat.com> <20150204140820.GS3032@redhat.com> In-Reply-To: <20150204140820.GS3032@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org 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