From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVZrx-0002lM-4P for qemu-devel@nongnu.org; Mon, 27 Jul 2009 19:44:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVZrr-0002i2-Qq for qemu-devel@nongnu.org; Mon, 27 Jul 2009 19:44:35 -0400 Received: from [199.232.76.173] (port=51563 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVZrr-0002hz-JD for qemu-devel@nongnu.org; Mon, 27 Jul 2009 19:44:31 -0400 Received: from mail-yx0-f188.google.com ([209.85.210.188]:64440) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVZrr-0007R3-8E for qemu-devel@nongnu.org; Mon, 27 Jul 2009 19:44:31 -0400 Received: by yxe26 with SMTP id 26so5976081yxe.4 for ; Mon, 27 Jul 2009 16:44:30 -0700 (PDT) Message-ID: <4A6E3BDC.8050101@codemonkey.ws> Date: Mon, 27 Jul 2009 18:44:28 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication References: <1248717876-17630-1-git-send-email-amit.shah@redhat.com> <4A6E0C9E.10908@codemonkey.ws> <20090727203214.GG15020@redhat.com> <20090727204627.GA32432@shareable.org> In-Reply-To: <20090727204627.GA32432@shareable.org> 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: Jamie Lokier Cc: Amit Shah , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org 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. 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. Regards, Anthony Liguori