From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1qZ-0006hR-As for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:26:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ1qW-000623-51 for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:26:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1qV-00061j-TC for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:26:28 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14FQRuM015302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 10:26:27 -0500 Date: Wed, 4 Feb 2015 15:26:23 +0000 From: "Daniel P. Berrange" Message-ID: <20150204152623.GA3032@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> <20150204143452.GV3032@redhat.com> <54D23501.5020200@redhat.com> <20150204151105.GY3032@redhat.com> <54D23932.8060101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54D23932.8060101@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 04:22:26PM +0100, Paolo Bonzini wrote: > > > On 04/02/2015 16:11, Daniel P. Berrange wrote: > > > For GIO/GIOChannel, you'd have to choose between zerocopy and many > > > syscalls, or one copy and few syscalls. Since every page has two iov > > > entries, one of which is just 8 bytes, one copy and few syscalls is > > > probably faster---but still only half the speed of writev. > > > > That could be an argument in favour of defining a QEMUIOChannel > > instead. The use of GIOChannel is only compelling if we gain some > > significant benefit from using the standard glib API in this scenario > > and I'm not clear that we really do, other than developer familiarity > > with glib. > > GIOChannel's advantage is that---even though it may not be used for > regular migration---integration with chardev would be really easy. If we did a QEMUIOChannel that was basically the same as IOChannel, but with support for iovec writev/readv it'd mostly be drop-in replacement for the chardev code I guess. > > > GIO could be compelling if we could leverage its TLS integration > > I agree. 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 :|