From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJrXT-0007A1-67 for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:38:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJrXS-00078r-BM for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:38:46 -0500 Received: from [199.232.76.173] (port=39803 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJrXS-00078e-4n for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:38:46 -0500 Received: from mail-gx0-f11.google.com ([209.85.217.11]:58371) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJrXR-0007EG-SF for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:38:45 -0500 Received: by gxk4 with SMTP id 4so9358650gxk.10 for ; Mon, 05 Jan 2009 07:38:45 -0800 (PST) Message-ID: <4962297E.4050702@codemonkey.ws> Date: Mon, 05 Jan 2009 09:38:38 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 0/5] Marry slirp and qemu character device. References: <20090105151459.3819.79836.stgit@dhcp-1-237.tlv.redhat.com> In-Reply-To: <20090105151459.3819.79836.stgit@dhcp-1-237.tlv.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Gleb Natapov wrote: > Trap TCP connection to special IP/port inside slirp and redirect its > traffic to a qemu character device. Add option to prevent connections > through slirp to outside world. Add migration support for "special" > sockets. This allow slirp to be used for secure communication between > host and guest management agents. > To catch-up the rest of the list. The overwhelming feeling on netdev was that we should just use TCP to communicate from the guest to the host instead of a special userspace transport. By using slirp to handle TCP within QEMU, we can expose the traffic to elsewhere as just a stream. Eventually, we'll add stuff to the distros and possibly to virtio-net to make the guest visible network adapter that is connected to "vmchannel" an isolated network from the rest of the guest networking stack, bypassing iptables, etc. This will make it always reliable. Regards, Anthony Liguori