From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKCIV-0000LI-JB for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:53:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKCIR-0000G3-SO for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:53:15 -0500 Received: from [199.232.76.173] (port=42257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKCIR-0000Fg-K9 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:53:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19032) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKCIR-0006AQ-8o for qemu-devel@nongnu.org; Mon, 14 Dec 2009 09:53:11 -0500 Message-ID: <4B265153.3050705@redhat.com> Date: Mon, 14 Dec 2009 16:53:07 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211223250.129675fc@redhat.com> <4B22B035.3010601@codemonkey.ws> <20091211233158.22e6681f@redhat.com> <4B22C093.2090806@codemonkey.ws> <4B231182.1080208@codemonkey.ws> <20091212144433.GA26966@random.random> <4B23B0BE.7080408@codemonkey.ws> <20091212160626.GB26966@random.random> <4B23D585.70400@codemonkey.ws> <4B241A99.2000704@redhat.com> <4B242B40.4050409@codemonkey.ws> <4B24C5EF.2090607@redhat.com> <4B264EC4.7020500@codemonkey.ws> In-Reply-To: <4B264EC4.7020500@codemonkey.ws> 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: Anthony Liguori Cc: Andrea Arcangeli , Paolo Bonzini , dlaor@redhat.com, qemu-devel@nongnu.org On 12/14/2009 04:42 PM, Anthony Liguori wrote: > I think it's a bit trickier though because ideally you would want to > use the vnc protocol to negotiate which vm you're connecting to. Right, of course. If the client can no longer choose the target using its port number, it has to select it in some other way. > That implies that you actually need to hand over the fd in a setup > state. It's complicated by any encryption protocol too. Yes - need to pass the encryption state. Hopefully the crypto stacks support this. -- error compiling committee.c: too many arguments to function