From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Scott <dave.scott@citrix.com>
Subject: [PATCH v2] implement libvirt-like 'channels' via PV
	consoles
Date: Mon, 16 Jun 2014 10:49:49 +0100
Message-ID: <1402912195-24732-1-git-send-email-dave.scott@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1WwTYN-0006oL-LR
	for xen-devel@lists.xenproject.org; Mon, 16 Jun 2014 09:50:15 +0000
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: xen-devel@lists.xenproject.org
Cc: ian.jackson@eu.citrix.com, David Scott <dave.scott@citrix.com>, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com
List-Id: xen-devel@lists.xenproject.org

Several libvirt applications (e.g. oVirt, CloudStack) make use of 'channels':
low-bandwidth private host <-> guest communication links which resemble serial
ports. Typical uses include:

  * initial VM configuration without using the network: read the config data
    directly from the channel on boot

  * controlling a guest agent: signal shutdown reqests, exchange clipboard data,
    trigger resolution changes

This patch set re-uses the existing PV console protocol implemented by qemu
to provide this service.

If you declare a channel in your .xl file as follows:

  channel = [ "type=socket,path=/tmp/mysock,name=guest-agent" ]

then an extra PV console will be added to your guest. This console has the
extra key in the frontend

  name = guest-agent

which allows udev scripts in the VM to create a named device in a well-known
location (e.g. /dev/xen-channels/guest-agent, similar to the KVM /dev/vports).
The qemu process in the backend domain will proxy the data to/from the named
Unix domain socket (in this case /tmp/mysock).

Note this mechanism is intended for low-bandwidth communication only. If an
application requires a high-bandwith connection then it should use a direct
vchan connection (and not proxy it via a qemu).

Changes since v1:

  * extend xl.cfg(5)
  * add docs/misc/channel.txt
  * libxl_types.idl: omit unnecessary init_val = 0
  * xl_cmdimpl.c: fixed over-long lines
  * xl_cmdimpl.c: use xrealloc (via ARRAY_EXTEND_INIT)
  * xl_cmdimpl.c: exit() on parse failure rather than ignore configuration
  * libxl_create.c: use libxl__device_console_init instead of memset
  * libxl_create.c: use libxl__strdup(NOGC rather than raw strdup
  * libxl.c: add name=<name> to console frontend
  * libxl.c: resolve the backend_domid from backend_domname
  * libxl_dm.c: channels[i].devid rather than i
  * libxl_dm.c: fix indentation
  * libxl_dm.c: use GCSPRINTF convenience macro

Signed-off-by: David Scott <dave.scott@citrix.com>