From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mm9xj-0006aA-2L for qemu-devel@nongnu.org; Fri, 11 Sep 2009 13:31:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mm9xc-0006TS-V0 for qemu-devel@nongnu.org; Fri, 11 Sep 2009 13:31:05 -0400 Received: from [199.232.76.173] (port=42766 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm9xc-0006T9-R9 for qemu-devel@nongnu.org; Fri, 11 Sep 2009 13:31:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57509) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mm9xc-0005l3-7D for qemu-devel@nongnu.org; Fri, 11 Sep 2009 13:31:00 -0400 Date: Fri, 11 Sep 2009 23:00:30 +0530 From: Amit Shah Message-ID: <20090911173030.GA27046@amit-x200.redhat.com> References: <1252684353-25067-1-git-send-email-amit.shah@redhat.com> <1252684353-25067-2-git-send-email-amit.shah@redhat.com> <1252684353-25067-3-git-send-email-amit.shah@redhat.com> <4AAA7813.1030904@codemonkey.ws> <20090911163410.GA25535@amit-x200.redhat.com> <4AAA7D0C.2020200@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAA7D0C.2020200@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCH 2/5] virtio-console: Add support for multiple ports for generic guest-host communication List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On (Fri) Sep 11 2009 [11:38:36], Anthony Liguori wrote: > Amit Shah wrote: >> There wasn't any consensus; the discussion just ended abruptly. >> > > At least Gerd and I were in violent agreement. I don't think anyone > disagreed. So how's suggestion about udev making symlinks based on the ports ids? >>> If a user does: >>> >>> qemu -M pc-0.11.0 -virtiocon vc -virtiocon vc >>> >>> This patch will break that guest. I think the best solution to this >>> is >> >> If there are multiple virtiocon devices specified, the first one will >> default to port #0. The second one will error out saying port 0 is >> taken. Isn't different from the current behaviour though. >> > > But that's a problem for -M pc-0.11.0. We need to have a way to specify > a command line syntax with -M pc-0.11.0 such that the machine created > matches what would have been created with qemu-0.11.0. Otherwise, we > have no hope of being able to do live migration or save/restore between > versions. I don't actually know if I understand this completely. However, with the current behaviour, qemu just exits saying something like too many virtio consoles since the current MAX_VIRTIO_CONSOLES is defined to 1. >>> We don't want to add PCI dependency to virtio console. It isn't >>> always used on platforms with PCI. >>> >> >> OK; there's a place where I need the qdev pointer from the PCIDevice. >> Any other way of obtaining that? >> > > Why do you need the qdev pointer? To init a chardev in the port hotplug case, qdev_init_chardev() needs the qdev pointer. >>> Need to integrate with QemuOpts. >> >> Wondering if it already entered master.. I'll sync up with kraxel if >> not. > > Yup, it's been there for a while. I remembered seeing it in your queue. Anyway it's simple enough and I'll do it. >>>> + register_savevm("virtio-console", -1, 2, virtio_console_save, virtio_console_load, s); >>>> >>> Should integrate with VMState. >>> >> >> I don't think virtio devices have been converted yet. >> > > I think that's next on Juan's list. Right; so we'll talk about that. Amit