Re: [Xen-devel] better console support

[Edward Pilatowicz <edward.pilatowicz@xxxxxxx>]

On Thu, Jan 25, 2007 at 06:55:29PM +0000, Keir Fraser wrote:
> On 25/1/07 18:47, "Joe Bonasera" <joe.bonasera@xxxxxxx> wrote:
>
> > The standard internal testing setup inside Sun that most
> > people run with is debug Xen and debug dom0 both
> > sharing either the VGA console or a single serial port console.
> > We also see field support of the eventual product needing the
> > ability to interact with both consoles on the same physical
> > device.  So we want to make the dom0 just handle sharing the console
> > as automatically as possible.
>
> You can already detect if Xen has locked out com1 or com2: try reading one
> of the UART registers (or perhaps write-then-read). If you get back all ones
> then you're locked out.
>

good to know.

so does xen have any uses for serial ports other than as a console
device?  if not then we can probably use this to detect an in use
port and switch the console to use hypervisor interfaces in this case.

> Maybe a vgakeep flag would be useful. We could add a SIF_VGA_IN_USE flag or
> something.
>

well, i don't think the xen vgakeep mode (which is essentially an
extension of the default vga mode) really provides us with a usable
console configuration since xen doesn't support any kind of keyboard
input.  (at least from my reading of the 3.0.3 code i think will only
take input from a serial port.)  so setting the xen to vga and vgakeep
and then setting the dom0 console to the hypervisor would essentially
give you a read-only console.

also, afaik, the current xen console io interfaces only allow simple
reads and writes of mostly uninterpreted character data, so essentially
the console is treated as serial device instead of a terminal.  so for
example, using the current xen console io interfaces there is no way
to change a character currently displayed on the screen without knowing
the current contents of the screen and re-writing out all those contents.

_if_ we want to be able to support access to the xen debugger on a
local vga console (and we could always decide that we don't) then i
think that we probably have a few options:

- add keyboard support to xen.  then xen could handle output on the vga
  device and input from the keyboard, and the dom0 OS console access
  would go through hypervisor interfaces.  also, modify the xen
  console interfaces to support some kind of "terminal" access to
  the console device (ie, write z at location x,y, etc)

- add keyboard support to xen.  then xen could handle output on the vga
  device and input from the keyboard.  have the host OS to also access
  the vga and keyboard devices directly.  (the tricky part here would
  be ensuring that xen and dom0 don't step on each others console
  output, although xen itself probably shouldn't be doing too much
  console output when it hasn't entered it's debugger.)

- allow xen to call a dom0's polled io console entry points to obtain
  input from and do output to the dom0 console device.  this would
  allow xen to use whatever console device the dom0 is configured to
  use and would require that the dom0 OS register it's polled io
  routines with xen.

ed

ps - fyi, i'm a xen newbie so if i've gotten anything wrong or any of
     this sounds far fetched and/or impossible then i appoligize for
     my ignorance.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel