From mboxrd@z Thu Jan 1 00:00:00 1970 From: NAHieu Subject: Re: How console data travel in Xen? Date: Fri, 1 Jul 2005 02:28:22 +0900 Message-ID: <5d7aca9505063010287ec8117a@mail.gmail.com> References: <5d7aca950506300841306bad7a@mail.gmail.com> <42C4190D.7000809@us.ibm.com> Reply-To: NAHieu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <42C4190D.7000809@us.ibm.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 7/1/05, Anthony Liguori wrote: > NAHieu wrote: >=20 > >Hello, > > > >I am trying to investigate in detail how console data go thru the Xen > >system. Suppose that I am running a domainU, when I type at the > >domainU console (I connect to the console with xencons or ssh), how > >data (from keyboard in this case) travel from low level (hardware) to > >Xen, then to dom0, then to domU? > > > > > There exists a well-known event channel and shared memory page between > each dom0 and domU which the control tools are responsible for setting > up (in Xend, that's xcs--in VM-Tools, that's xenctld). The shared > memory page is defined by the shared_info_frame which is queriable as > part of getdomaininfo(). The event channel is chosen by the control > tools and is almost always 1. >=20 > The event channel and shared memory page make up the control channel. > The shared memory page is used as a ring queue for messages (see > /usr/include/xen/io/domain_controller.h) and the event channel is a > notification message to say when a new message has arrived. >=20 > One of the message types is CMSG_CONSOLE. It has one message subtype > CMSG_CONSOLE_DATA. Console data (input and output) is passed in 60 byte > chunks using this message type between dom0 and domU. This is handled > at drivers/xen/console/console.c in domU (in the kernel tree) and in > tools/xcs/*.c in dom0 (or xenctld/console.c in VM-Tools). In VM-Tools, > the console messages are just put into a queue until a file (usually a > pty) is associated with the device in which case everything is > dumped/read from the file. >=20 > The Xend/xcs architecture is a bit more complex. xcs forwards all > messages over two sockets to Xend. Xend then dispatches these messages > internally. The messages are then read/written to a socket. The stuff > that's unique to the console is mostly handled in > tools/python/xen/xend/server/console.py Anthony, thank you for a great detail explaination. These information is really helpful to me. But still few questions stand: how do console data go from HW to Xen, then to dom0? (the above explaination is only about sessions between dom0 and domU) Thank you a lot, Hieu