From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtDhL-0006xL-0v for qemu-devel@nongnu.org; Thu, 01 Oct 2009 00:55:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtDhG-0006wx-4A for qemu-devel@nongnu.org; Thu, 01 Oct 2009 00:55:22 -0400 Received: from [199.232.76.173] (port=60913 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtDhF-0006wu-WD for qemu-devel@nongnu.org; Thu, 01 Oct 2009 00:55:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50590) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtDhF-0004oN-A5 for qemu-devel@nongnu.org; Thu, 01 Oct 2009 00:55:17 -0400 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n914tFkB010532 for ; Thu, 1 Oct 2009 00:55:16 -0400 Date: Thu, 1 Oct 2009 10:24:39 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Message-ID: <20091001045439.GA18563@amit-x200.redhat.com> References: <1254225888-17093-1-git-send-email-amit.shah@redhat.com> <1254225888-17093-2-git-send-email-amit.shah@redhat.com> <1254225888-17093-3-git-send-email-amit.shah@redhat.com> <1254225888-17093-4-git-send-email-amit.shah@redhat.com> <4AC24C34.2080609@redhat.com> <20090930044724.GA28188@amit-x200.redhat.com> <4AC31E03.8000904@redhat.com> <20090930155534.GB1011@amit-x200.redhat.com> <4AC3A5E6.6070703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AC3A5E6.6070703@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On (Wed) Sep 30 2009 [20:39:34], Gerd Hoffmann wrote: >> BTW the kernel too doesn't support multiple devices so far. > > Needs fixing too ;) Agreed :-) I've fixed multiple devices in qemu. >>> I'd suggest to look what do do when another user which wants buffering >>> comes along. Might be the requirements are different, so it wouldn't >>> work anyway. >>> >>> Also when you pass around pointers to VirtConPortBuffer the port drivers >>> can implement buffering very easily. >> >> It will mostly be duplicated. Right now, I pass on an entire message as >> was passed on by the kernel in one write() request. If I start passing >> around buffers, it'll be incomplete messages (eg, an 8K write request in >> the kernel will be split in two buffers of 4K each -- or three buffers >> with the last one containing a few bytes). I don't think I want the ports >> to worry about that. The ports should just get the entire message. > > Sure. I think there is a misunderstanding here. I meant only the > "buffer messages when unconnected" thing. Reassembling the messages in > the core and forward only complete messages to the ports is fine. OK; so in that case, passing a ptr to the buffer and its length is fine, no? >> Basically I've now dropped the old -virtioconsole argument. >> >> So one has to do: >> >> -device virtio-console-pci -device virtioconsole ... >> >> to start a console. > > If you do '-device virtio-console-pci -device virtio-port' (i.e. no > console) and boot a old guest kernel which expects a (single) console > being there, what will happen? OK -- I get what you're saying now. However, I don't see any problem here. If there is no virtioconsole specified to qemu, there's no reason to expect a console in the guest. That was the case in the past and is the case now as well. The difference is earlier, when probe() in the guest was called, it definitely meant the existence of a console. Now, even if probe() is invoked, it doesn't mean a console was found. But this hardly is a concern. Also, the way to attach to a virtioconsole is by spawning a tty on /dev/hvc0. If no -virtioconsole is specified on the host command line, no hvc device is spawned on the guest. So things are as they are. Amit