Re: [Xen-devel] [PATCH v5 for-4.5 1/2] libxl: add support for 'channels'

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

On 22 Sep 2014, at 17:17, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

> David Scott writes ("[PATCH v5 for-4.5 1/2] libxl: add support for 
> 'channels'"):
>> A 'channel':
>>  - is a low-bandwidth private communication channel that resembles
>>    a physical serial port.
>>  - is implemented as a PV console with a well-known string name
>>    which is used to hook the channel to the appropriate software
>>    in the guest (i.e. some kind of guest agent).
>>  - has a backend 'connection' which describes what should happen
>>    to the data.
> 
> This looks good in principle.
> 
> I have a couple of easy quibbles:
> 
> You have forgotten to document that you transport the channel name in
> xenstore in the subkey `name'.  This should be in your `console.txt'
> patch I think, given that xenstore-paths.markdown refers to that for
> all the nodes in .../console.
> 
> And the interaction between consoles in the console part of the domain
> configuration and the channels listed in the channels part, should be
> documented.  (Even if it's just that consoles always have no name and
> channels always have one.)
> 
> 
> I have a harder one:
> 
>> +int libxl__init_console_from_channel(libxl__gc *gc,
>> +                                     libxl__device_console *console,
>> +                                     int dev_num,
>> +                                     libxl_device_channel *channel)
> 
> AFAICT this function is used to recreate the domain's channel
> configuration info for the benefit of libxl's caller (making
> enquiries) and setting up the qemu arguments.
> 
> But nowadays, following Wei's save/restore/JSON patches, I think we
> would expect libxl to retrieve this information from the JSON
> configuration.  That is, the console information should be in the
> stored JSON config and can be retrieved from there.
> 
> (There are also unfortunate security implications to reading the
> backend directory like that - if we have a driver domain, the qemu
> might get untrustworthy paths.)

Sorry I missed this bit, thanks Wei for highlighting it.

I agree that we must be careful not to start a driver domain and tell it
‘talk to the socket at path x’ when in fact ‘x’ is in a different domain.
At the moment paths are in the driver domain and the person who writes
the domain config must consider this when they choose their driver domain.

Thinking about the future, although we could arrange it such that the
data gets routed to other places (e.g. run qemu/xenconsoled in the driver
domain, have it proxy the data over a vchan, have a thing in dom0 proxy
to the right socket) I suspect that we’ll want to add additional
‘connection’ behaviours which reference resources via global names rather
than local ones. I quite like the idea of adding some kind of URI to
name a network endpoint and have the driver domain proxy all the data
to/from there.

I’m not totally sure that’s what you were getting at — sorry if I’ve missed
the point!

Cheers,
Dave

> Wei, am I right ?
> 
> 
> Thanks,
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


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