Re: [Xen-devel] [PATCH v2 6/6] Add a general description of the channel mechanism to docs/misc/

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

On 18 Jun 2014, at 15:43, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> On Wed, 2014-06-18 at 15:37 +0100, Dave Scott wrote:
>>> Is this stuff all forward compatible with the existing xenconsoled etc?
>>> What stops it trying to manage these guys?
>> 
>> To handle this through xenconsoled would involve:
> 
> What I meant was why does xenconsoled not try and manage these today and
> get in the way? To which the answer is:
> 
>> 1. extending xenconsoled to watch for console device backends (like
>> any other device backend). Currently xenconsoled is limited to the
>> initial console only.
> 
> This (which I wasn't aware of, I thought it handled multiple).
> 
> ISTR there is a key in their which allows qemu or xenconsoled to provide
> this initial console too.

That’s right — there’s a xenstore key type = (ioemu | xenconsoled). (Note to 
self: I’d better rename my ‘type’ key)

> 
>> I took the qemu approach for the initial implementation because this
>> is how libxl arranges for  the second/third/fourth/… consoles to be
>> served (possibly because xenconsoled has never been extended).
>> Personally I’d like to switch over to xenconsoled eventually rather
>> than rely on qemu for ever more stuff.
> 
> I'll defer to Stefano on this. I thought the normal qemu (upstream)
> approach was:
> 
>      * emulated stuff via command-line/qmp but never xenstore (in
>        contrast with qemu-trad which played all sorts of tricks to
>        insert IDE disks from xenstore).
>      * PV stuff via watching xenstore backend paths.
> 
> Do I understand you correctly that there is a qemu patch involved in all
> this, or does it just happen to work if you feed it the correct cmdline
> runes?

No qemu patch needed — once I figured out the right command line magic it 
stopped crashing and started working :-)

My (primitive) understanding is that, if you run a qemu for a PV guest (see 
libxl_dm.c:libxl__need_xenpv_qemu) then it’ll act as the backend for qdisk 
backends and these extra consoles where libxl has written ‘type=ioemu’. If 
xenconsoled were extended to support these then libxl would write 
‘type=xenconsoled’ and qemu would ignore them.

In the qemu code the xen console backends (tools/qemu-xen-dir/hw/xen_console.c) 
are qemu “chardev” devices which gives you access to the exciting world of 
qemu-char.c:

static const struct {
    const char *name;
    CharDriverState *(*open)(QemuOpts *opts);
} backend_table[] = {
    { .name = "null",      .open = qemu_chr_open_null },
    { .name = "socket",    .open = qemu_chr_open_socket },
    { .name = "udp",       .open = qemu_chr_open_udp },
    { .name = "msmouse",   .open = qemu_chr_open_msmouse },
    { .name = "vc",        .open = text_console_init },
#ifdef _WIN32
    { .name = "file",      .open = qemu_chr_open_win_file_out },
    { .name = "pipe",      .open = qemu_chr_open_win_pipe },
    { .name = "console",   .open = qemu_chr_open_win_con },
    { .name = "serial",    .open = qemu_chr_open_win },
    { .name = "stdio",     .open = qemu_chr_open_win_stdio },
#else
    { .name = "file",      .open = qemu_chr_open_file_out },
    { .name = "pipe",      .open = qemu_chr_open_pipe },
    { .name = "pty",       .open = qemu_chr_open_pty },
    { .name = "stdio",     .open = qemu_chr_open_stdio },
#endif
#ifdef CONFIG_BRLAPI
    { .name = "braille",   .open = chr_baum_init },
#endif
#if defined(__linux__) || defined(__sun__) || defined(__FreeBSD__) \
    || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) \
    || defined(__FreeBSD_kernel__)
    { .name = "tty",       .open = qemu_chr_open_tty },
#endif
#if defined(__linux__) || defined(__FreeBSD__) || defined(__DragonFly__) \
    || defined(__FreeBSD_kernel__)
    { .name = "parport",   .open = qemu_chr_open_pp },
#endif
#ifdef CONFIG_SPICE
    { .name = "spicevmc",     .open = qemu_chr_open_spice },
#endif
};

Cheers,
Dave


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