Re: port-xen/40675: Xen 3.3: guest serial console not functional

["Christoph Egger" <Christoph_Egger%gmx.de@localhost>]

The following reply was made to PR port-xen/40675; it has been noted by GNATS.

From: "Christoph Egger" <Christoph_Egger%gmx.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-xen/40675: Xen 3.3: guest serial console not functional
Date: Thu, 19 Feb 2009 11:22:00 +0100

 Below the referenced e-mail.
 
 On Sunday 17 August 2008 14:01:09 Christoph Egger wrote:
 > Hi,
 >
 > Something strange is going on with the xenconsole:
 >
 > There is no console output if domain id is "1".
 > This impacts both PV and HVM guests (latter one only
 > if serial console is configured).
 >
 > Console output is there if domain id is anything else
 > than "1".
 >
 > Console input is working so you can work blindly on it
 > (or connect via ssh :)
 >
 >
 > How to reproduce:
 >
 > Boot your Xen machine, make sure xend and xenbackendd
 > are running.
 >
 > Launch your first guest and connect to the console with:
 >
 > xm create -c <guest-config>
 >
 > or
 >
 > xm create <guest-config>
 > xm console 1
 >
 >
 > How xenconsole is supposed to work:
 >
 > Interaction between Dom0 and the DomU happens through
 > a console ring-buffer, each entry can hold max. 512 chars.
 >
 > The ring-buffer frontend is in the DomU, the ring-buffer
 > backend in the Dom0.
 > xenstored runs in the Dom0 and holds the information how to
 > access the ring-buffer.
 >
 > xenconsoled opens one tty for each launched domU via openpty().
 > xenconsoled tells xenstored which pty (e.g. /dev/pts/3) is
 > used for that domU.
 > The masterfd will be used for console input/output.
 > It writes anything read from the ring-buffer into
 > the pty (= console output) and writes anything read from the pty
 > into the ring-buffer (= console input).
 > xenconsoled multiplexes the ring-buffer content to the different
 > domUs ptys.
 >
 > When the user connects to the console, the xenconsole client
 > runs. It queries xenstored which pty to use that domU.
 > It uses select() to wait for any input from stdin or any output
 > from the pty becoming available.
 > When the user types something on the keyboard, xenconsole reads
 > this from stdin and writes this into the pty and returns
 > back to select().
 > When output fromt the pty is available, xenconsole reads it
 > from the pty and writes this to stdout.
 >
 >
 > What I figured out or what is going wrong:
 >
 > I ktraced xenconsoled, launched the first guest (= domain id 1)
 > and connected to its console.
 >
 > In the ktrace I saw, xenconsoled (= daemon)
 > actually receives the console output
 > and writes into the pty.
 >
 >
 > I also ktraced xenconsole and I also put some debug fprintf(stderr, ...)
 > into xenconsole to noticed, select() reacts as expected on
 > console input.
 > But: If domain id is "1", select() does not notice when an output is
 > available. That is why no console output is there and why you can work
 > blindly on the guest.
 > If domain id is != "1", select() actually does notice when an output
 > is available and xenconsole writes this to stdout.
 >
 >
 >
 > Open questions:
 >
 > Why does select() not notice when the domU pty change? And why
 > only on domain id  "1" ?
 >
 > Is there a (hidden) relation between select() and Xen-kernel code ?
 >
 > select(), openpty() and ptyfs are supposed to work ?
 
 I figured out, this issue is not bound to domain id "1".
 If you start some HVM guests which don't have a serial console
 first and then a guest with a serial console, then you
 the first guest with a serial console is impacted by this issue.
 
 I suspect the bug in xenconsoled (daemon) since it does
 the terminal settings. I think something is missing in
 terminal initializing. But I'm stuck there.
 
 Christoph
 
 -- 
 Greetings,
 
 Christoph