From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37028 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgOMc-00083t-51 for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:45:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgOMa-0003jo-Sb for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:45:30 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:53830) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgOMa-0003jG-LV for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:45:28 -0400 Received: by qwf6 with SMTP id 6so328631qwf.4 for ; Tue, 03 Aug 2010 13:45:27 -0700 (PDT) Message-ID: <4C587FE2.3010405@codemonkey.ws> Date: Tue, 03 Aug 2010 15:45:22 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] RFC adding ioctl's to virtserial/virtconsole References: <1998763220.603051280770128553.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> <4C5703A1.2040500@codemonkey.ws> <4C57D768.20401@redhat.com> <4C5815BC.6030600@codemonkey.ws> <4C583594.8060903@redhat.com> <4C5839D0.1060109@codemonkey.ws> <4C5846DD.90209@redhat.com> <4C58479E.2000805@codemonkey.ws> <4C584B8D.6090405@redhat.com> <4C58577C.90408@codemonkey.ws> <4C587EE9.3070306@redhat.com> In-Reply-To: <4C587EE9.3070306@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Amit Shah , Anthony Liguori , Alon Levy , qemu-devel On 08/03/2010 03:41 PM, Gerd Hoffmann wrote: > On 08/03/10 19:53, Anthony Liguori wrote: >> On 08/03/2010 12:02 PM, Gerd Hoffmann wrote: >>> On 08/03/10 18:45, Anthony Liguori wrote: >>>> On 08/03/2010 11:42 AM, Gerd Hoffmann wrote: >>>>> spice-vmc code registers/unregisters the interface within the spice >>>>> server. So the interface is only activated in case the guest uses it. >>>>> Spice client sees the interface being active or not and can act >>>>> accordingly. >>>> >>>> So we have to migrate connected state? >>> >>> virtio-serial handles that already. >> >> And we have to propagate this upon load to the char device backend. > > Happens too, by calling port->guest_open() if needed in loadvm_post(). > >> Do we assume that the chardev is in the CONNECTED state initially? If we >> do a loadvm at run time while we're in the CONNECTED state, do we >> generate a DISCONNECTED followed by CONNECTED state transition? If we >> loadvm to a state where we were in the DISCONNECTED state, does that >> generate DISCONNECTED followed by CONNECTED followed by DISCONNECTED or >> just DISCONNECTED? >> >> This is exactly the type of problem that we've had in the past by not >> having an API that clearly forces management of life cycle. > > That indeed must be cleanly defined and for best results also enforced > in some way, say using asserts(). That needs some bigger planning and > not some ad-hoc "Oh lets us quickly add this" patching though. When > re-designing chardevs I wanna do it once and wanna do it right. > > Are there BoF slots @ kvm forum? Yes. > I can try to put together something (current pain points + feature > wishlist + better chardev data structures + better chardev api) to > kick a discussion either in Boston or at qemu-devel. Will take some > time though. That would be really helpful! Regards, Anthony Liguori > cheers, > Gerd >