Re: [Xen-devel] [PATCH v2 1/6] libxl: add a list of abstract 'channels' to the domain config

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi,

On 18 Jun 2014, at 14:27, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> On Mon, 2014-06-16 at 10:49 +0100, David Scott wrote:
>> A 'channel' is a low-bandwidth private communication channel that
>> resembles a physical serial port. Example uses include:
>> 
>>  * providing initial VM configuration without having to use the
>>    network
>>  * signalling a guest agent
>> 
>> Every channel has a string 'name' which the VM can use to find
>> the appropriate handler. Each channel has an implementation 'type'
>> which currently includes:
>> 
>>  * NONE: reads will block, writes will be thrown away
> 
> What's this useful for?

I was thinking of this particular one as a “/dev/null” equivalent — the virtual 
device is present in the guest (which might be needed to trigger some 
side-effect) but the output isn’t important.

It appealed to me as a kind of a base case, but I grant you that it’s not the 
most useful feature in the world :-)

> 
>>  * PTY: the I/O surfaces as a pty in the backend domain
>>  * PATH: writes are appended to a log file in the backend domain
> 
> PATH is quite a generic name for that.

Hm, perhaps calling it FILE would be better — this is what libvirt and qemu 
both use.

> Do reads block?

I believe so.

>>  * SOCKET: a listening Unix domain socket accepts a connection in
>>    the backend domain and proxies

The SOCKET type is the most useful kind IMHO.

So libvirt and qemu support a bunch of other types: TCP connect to …; receive 
connection and proxy … (and probably more in future). Instead of trying to 
mirror the libvirt/qemu APIs we could fall back and only support the “SOCKET” 
type, and require users to move the data wherever they want via a proxy like 
“socat”. These channels are low-bandwidth so efficiency is not really a concern.

>> 
>> Signed-off-by: David Scott <dave.scott@xxxxxxxxxx>
>> ---
>> tools/libxl/libxl_types.idl |   21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>> 
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 52f1aa9..5671d86 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -51,6 +51,17 @@ libxl_domain_type = Enumeration("domain_type", [
>>     (2, "PV"),
>>     ], init_val = -1)
>> 
>> +libxl_channel_type = Enumeration("channel_type", [
>> +    # Connected to nothing:
>> +    (0, "NONE"),
>> +    # Connect to a pty in the backend domain:
>> +    (1, "PTY"),
>> +    # Spool output to a file in the backend domain:
>> +    (2, "PATH"),
>> +    # Listen on a Unix domain socket in the backend domain:
>> +    (3, "SOCKET"),
>> +    ])
>> +
>> libxl_device_model_version = Enumeration("device_model_version", [
>>     (0, "UNKNOWN"),
>>     (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
>> @@ -457,6 +468,15 @@ libxl_device_vtpm = Struct("device_vtpm", [
>>     ("uuid",             libxl_uuid),
>> ])
>> 
>> +libxl_device_channel = Struct("device_channel", [
>> +    ("backend_domid", libxl_domid),
>> +    ("backend_domname", string),
>> +    ("devid", libxl_devid),
>> +    ("name", string),
>> +    ("type", libxl_channel_type),
>> +    ("path", string),
> 
> Is path valid for all types?
> 
> If not then a KeyedUnion would be the way to go.

OK.

So I think the question I’m most unsure about is: should we keep the notion of 
‘type’ here (and switch to a KeyedUnion) or treat everything in a uniform way 
(e.g. socket) and let someone else to the plumbing?

Thanks,
Dave

> 
>> +])
>> +
>> libxl_domain_config = Struct("domain_config", [
>>     ("c_info", libxl_domain_create_info),
>>     ("b_info", libxl_domain_build_info),
>> @@ -467,6 +487,7 @@ libxl_domain_config = Struct("domain_config", [
>>     ("vfbs", Array(libxl_device_vfb, "num_vfbs")),
>>     ("vkbs", Array(libxl_device_vkb, "num_vkbs")),
>>     ("vtpms", Array(libxl_device_vtpm, "num_vtpms")),
>> +    ("channels", Array(libxl_device_channel, "num_channels")),
>> 
>>     ("on_poweroff", libxl_action_on_shutdown),
>>     ("on_reboot", libxl_action_on_shutdown),


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel