From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtHTD-0006t0-Sw for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:57:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtHT9-0006oP-Uh for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:57:03 -0400 Received: from [199.232.76.173] (port=38709 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtHT9-0006oC-L6 for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:56:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20812) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtHT9-00070A-1U for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:56:59 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n918uwA2018783 for ; Thu, 1 Oct 2009 04:56:58 -0400 Date: Thu, 1 Oct 2009 14:26:20 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Message-ID: <20091001085620.GB8385@amit-x200.redhat.com> References: <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> <20091001045439.GA18563@amit-x200.redhat.com> <4AC46A7A.6030809@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AC46A7A.6030809@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 [10:38:18], Gerd Hoffmann wrote: > Hi, > >>> 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? > > Will work. We need some clear rules for buffer memory though. Possible > ways to deal with it: > > (1) core owns the buffer. If the port driver wants to keep the > content it has to memcpy() it to own memory. > (2) have_data() callback transfers buffer ownership from core to > the port driver. It is the port drivers job to free the memory > when it doesn't need it any more. > (3) reference-count the buffers. > > For (1) + (2) both buffer struct and ptr+len will work. > > For (3) ptr+len wouldn't work though, you'll need some struct containing > ptr, len, refcount and helper functions to get/put buffers. Yeah; Currently it's only (1). But I'm now thinking of doing (2). One concern Yaniv raised was a port driver may not consume all the data right away, so it's better to let the port do the buffer management. >>> 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! Amit