From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Scott Subject: Re: [PATCH v2 6/6] Add a general description of the channel mechanism to docs/misc/ Date: Wed, 18 Jun 2014 15:00:43 +0000 Message-ID: <0A51DCA5-46AC-4E19-850A-0AE40E4411AC@citrix.com> References: <1402912195-24732-1-git-send-email-dave.scott@citrix.com> <1402912195-24732-7-git-send-email-dave.scott@citrix.com> <1403098902.6568.17.camel@kazak.uk.xensource.com> <1403102585.6568.63.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WxHLz-00068B-CG for xen-devel@lists.xenproject.org; Wed, 18 Jun 2014 15:00:47 +0000 In-Reply-To: <1403102585.6568.63.camel@kazak.uk.xensource.com> Content-Language: en-US Content-ID: <651F718AD4F3B14A9905320A430605D6@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xenproject.org" , Wei Liu , Stefano Stabellini , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 18 Jun 2014, at 15:43, Ian Campbell 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=92s right =97 there=92s a xenstore key type =3D (ioemu | xenconsoled).= (Note to self: I=92d better rename my =91type=92 key) > = >> I took the qemu approach for the initial implementation because this >> is how libxl arranges for the second/third/fourth/=85 consoles to be >> served (possibly because xenconsoled has never been extended). >> Personally I=92d 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 =97 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=92ll act as the backend for qdi= sk backends and these extra consoles where libxl has written =91type=3Dioem= u=92. If xenconsoled were extended to support these then libxl would write = =91type=3Dxenconsoled=92 and qemu would ignore them. In the qemu code the xen console backends (tools/qemu-xen-dir/hw/xen_consol= e.c) are qemu =93chardev=94 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[] =3D { { .name =3D "null", .open =3D qemu_chr_open_null }, { .name =3D "socket", .open =3D qemu_chr_open_socket }, { .name =3D "udp", .open =3D qemu_chr_open_udp }, { .name =3D "msmouse", .open =3D qemu_chr_open_msmouse }, { .name =3D "vc", .open =3D text_console_init }, #ifdef _WIN32 { .name =3D "file", .open =3D qemu_chr_open_win_file_out }, { .name =3D "pipe", .open =3D qemu_chr_open_win_pipe }, { .name =3D "console", .open =3D qemu_chr_open_win_con }, { .name =3D "serial", .open =3D qemu_chr_open_win }, { .name =3D "stdio", .open =3D qemu_chr_open_win_stdio }, #else { .name =3D "file", .open =3D qemu_chr_open_file_out }, { .name =3D "pipe", .open =3D qemu_chr_open_pipe }, { .name =3D "pty", .open =3D qemu_chr_open_pty }, { .name =3D "stdio", .open =3D qemu_chr_open_stdio }, #endif #ifdef CONFIG_BRLAPI { .name =3D "braille", .open =3D chr_baum_init }, #endif #if defined(__linux__) || defined(__sun__) || defined(__FreeBSD__) \ || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__= ) \ || defined(__FreeBSD_kernel__) { .name =3D "tty", .open =3D qemu_chr_open_tty }, #endif #if defined(__linux__) || defined(__FreeBSD__) || defined(__DragonFly__) \ || defined(__FreeBSD_kernel__) { .name =3D "parport", .open =3D qemu_chr_open_pp }, #endif #ifdef CONFIG_SPICE { .name =3D "spicevmc", .open =3D qemu_chr_open_spice }, #endif }; Cheers, Dave