From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ12g-0008R1-VV for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:35:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ12f-0003RW-Qm for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:34:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ12f-0003RF-JN for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:34:57 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14EYu2L001746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 09:34:56 -0500 Date: Wed, 4 Feb 2015 14:34:52 +0000 From: "Daniel P. Berrange" Message-ID: <20150204143452.GV3032@redhat.com> References: <20150204113229.GN3032@redhat.com> <54D213E0.8090408@redhat.com> <20150204130041.GQ3032@redhat.com> <54D221BC.50008@redhat.com> <20150204140820.GS3032@redhat.com> <54D22B5A.5020904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54D22B5A.5020904@redhat.com> Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org 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 :|