From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtHBG-0001Rh-91 for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:38:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtHBB-0001Of-Dx for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:38:29 -0400 Received: from [199.232.76.173] (port=46501 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtHBB-0001OX-28 for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:38:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4690) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtHBA-0003nU-IF for qemu-devel@nongnu.org; Thu, 01 Oct 2009 04:38:24 -0400 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n918cLi9012755 for ; Thu, 1 Oct 2009 04:38:21 -0400 Message-ID: <4AC46A7A.6030809@redhat.com> Date: Thu, 01 Oct 2009 10:38:18 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports 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> <20091001045439.GA18563@amit-x200.redhat.com> In-Reply-To: <20091001045439.GA18563@amit-x200.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu-devel@nongnu.org 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. >> 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. cheers, Gerd