From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ7Bq-0000FT-P8 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:41:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ7Bm-0000D6-R0 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:41:38 -0400 Received: from [199.232.76.173] (port=55525 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ7Bm-0000D0-Lg for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:41:34 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]:63571) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ7Bm-0001Rt-1V for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:41:34 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.14.3/8.13.8) with ESMTP id n5NEeWBh306566 for ; Tue, 23 Jun 2009 14:40:32 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5NEeWiv3186798 for ; Tue, 23 Jun 2009 16:40:32 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5NEeVZc030806 for ; Tue, 23 Jun 2009 16:40:31 +0200 From: Christian =?iso-8859-1?q?Borntr=E4ger?= Subject: Re: [Qemu-devel] virtio-serial: A guest <-> host interface for simple communication Date: Tue, 23 Jun 2009 16:40:30 +0200 References: <1245760953-32139-1-git-send-email-amit.shah@redhat.com> <200906231558.33794.borntraeger@de.ibm.com> <200906231516.15470.paul@codesourcery.com> In-Reply-To: <200906231516.15470.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906231640.30915.borntraeger@de.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Amit Shah , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Am Dienstag 23 Juni 2009 16:16:13 schrieb Paul Brook: > > I did some work on virtio-console, since kvm on s390 does not provide any > > other. I dont think we should mix two different types of devices into one > > driver. The only thing that these drivers have in common, is the fact > > that there are two virtqueues, piping data (single bytes or larger > > chunks). So you could make the same argument with the first virtio_net > > driver (the one before GSO) - which is obviously wrong. The common part > > of the transport is already factored out to virtio_ring and the > > transports. > > virtio-net is packet based, not stream based. You can argue that virtio-console is also packet based. The input buffer can accept up to 4K in one buffer and the console code can also submit larger chunks to virtio_console. > > In addition there are two ABIs involved: a userspace ABI (/dev/hvc0) and > > a guest/host ABI for this console. (and virtio was not meant to be a > > KVM-only interface, that we can change all the time). David A. Wheeler's > > 'SLOCCount' gives me 141 lines of code for virtio_console.c. I am quite > > confident that the saving we could achieve by merging these two drivers > > is not worth the hazzle. > > AFAICS the functionality provided is exactly the same. The host API is > identical, and the guest userspace API only has trivial differences (which > could be eliminated with a simple udev rule). By my reading virtio-serial > makes virtio-console entirely redundant. How can you know, that the userspace API only has trivial differences, if the question below is not answered? > > Discussion about merging the console code into this distracts from the > > main problem: To get the interface and functionality right before it > > becomes an ABI (is it /dev/ttyS, network like or is it something > > completely different?). > > Ah, now that's a different question. I don't know what the requirements are > for the higher level vmchannel interface. However I also don't care. You should care, because it might have an impact if two serial lines are really the right solution for the vmchannel. One thing that I forgot: You should be warned that hvc_console sometimes can be a real PITA. A while ago I tried to change virtio_console to support more than one console and hotplug and failed to find a proper solution that can handle all the subtle console/tty register/unregister combinations. You dont want to adopt new code to fit to hvc_console - leave it in virtio_console...