From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVk35-0007sb-At for qemu-devel@nongnu.org; Tue, 28 Jul 2009 06:36:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVk2z-0007rW-0S for qemu-devel@nongnu.org; Tue, 28 Jul 2009 06:36:45 -0400 Received: from [199.232.76.173] (port=55000 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVk2y-0007rQ-Fd for qemu-devel@nongnu.org; Tue, 28 Jul 2009 06:36:40 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57016) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVk2x-0000JC-V5 for qemu-devel@nongnu.org; Tue, 28 Jul 2009 06:36:40 -0400 Date: Tue, 28 Jul 2009 16:06:24 +0530 From: Amit Shah Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication Message-ID: <20090728103624.GA5176@amit-x200.redhat.com> References: <1248717876-17630-1-git-send-email-amit.shah@redhat.com> <4A6E0C9E.10908@codemonkey.ws> <20090727203214.GG15020@redhat.com> <20090727204627.GA32432@shareable.org> <4A6E3BDC.8050101@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6E3BDC.8050101@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org On (Mon) Jul 27 2009 [18:44:28], Anthony Liguori wrote: > Jamie Lokier wrote: >> With multiple X servers, there can be more than one currently logged in user. >> >> Same with multiple text consoles - that's more familiar. >> >> Which one owns /dev/vmch3? >> > > For a VMM, copy/paste should work with whatever user has the active X > session that's controlling the physical display. > > Yes, it could get complicated if we supported multiple video cards, but > fortunately we don't :-) > > I really think you need to have a copy/paste daemon that allows multiple > X sessions to connect to it and then that daemon can somehow determine > who is the "active" session. > > This is part of the reason I've been pushing for a concrete example. > All the signs here point to a privileged daemon that delegates to > multiple users. I think just about any use-case will have a similar > model. > > It really suggests that you need _one_ vmchannel that's exposed to > userspace with a single userspace daemon that consumes it. You want the > flexibility of a userspace daemon in determining how you multiplex and > do security. I don't think it's something you want to bake into the > userspace/kernel interface. Right; use virtio just as the transport and all the interesting activity happens in userspaces. That was the basis with which I started. I can imagine dbus doing the copy/paste, lock screen, etc. actions. However for libguestfs, dbus isn't an option and they already have some predefined agents for each port. So libguestfs is an example for a multi-port usecase for virtio-serial. > And if you have a single daemon that serves vmchannel sessions, that > daemon can make it transparent whether the session is going over > /dev/ttyS0, a network device, /dev/hvc1, etc. or /dev/vmch0. it doesn't matter. All minimal virtio devices will look the same. Pop buffers, populate them, push them, etc. Amit