From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtJE0-0001s5-5A for qemu-devel@nongnu.org; Thu, 01 Oct 2009 06:49:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtJDv-0001mw-62 for qemu-devel@nongnu.org; Thu, 01 Oct 2009 06:49:27 -0400 Received: from [199.232.76.173] (port=41565 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtJDu-0001mj-Vw for qemu-devel@nongnu.org; Thu, 01 Oct 2009 06:49:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44691) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtJDu-0000Vq-ER for qemu-devel@nongnu.org; Thu, 01 Oct 2009 06:49:22 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n91AnLE0002588 for ; Thu, 1 Oct 2009 06:49:21 -0400 Date: Thu, 1 Oct 2009 16:18:43 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Message-ID: <20091001104843.GA12334@amit-x200.redhat.com> References: <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> <20091001045439.GA18563@amit-x200.redhat.com> <4AC46A7A.6030809@redhat.com> <20091001085620.GB8385@amit-x200.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091001085620.GB8385@amit-x200.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 (Thu) Oct 01 2009 [14:26:20], Amit Shah wrote: > >>> 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. > > > > True for new guest kernels, they simply don't create a hvc. > > Question is what *old* guest kernels will do in that case. > > If the guest kernel doesn't support the new virtio feature > VIRTIO_F_MULTIPORT, then we disable all this functionality and only > allow one port. That one port has to be the console port. I've tested > this combination, btw. > > However, it's possible that some of the checks got lost in the latest > rework and that port 0 isn't actually a console port. I'll go through > init code again to ensure this. Thanks for explaining the scenario! There are a couple of problems with what I said: - I had to make some changes in the kernel driver because hvc didn't work as I expected. If initial consoles were spawned (currently only on s390 and powerpc), new ports have to arrive in the same order as init consoles were spawned. This means /dev/console will be bound to the first console port that gets initialised. It's desirable to always have port0 get that distinction. - We won't know if the guest supports multiple ports till the guest driver does a probe(). That's much much later than when port drivers in qemu are initialised. So we will have to spawn a console port at id 0 when the bus is initialised. There are a couple of problems though: - How to identify which chardev to associate the port#0 with? - If there is a virtioconsole device specified on the command line, should that be used as port0? Or should that mean we spawn two consoles? I guess for both these cases, some special command line tweaks will be needed? Or keep the old '-virtioconsole' parameter and put that up as port0? Amit