better console support

better console support

[Joe Bonasera]

There seems to be a some confusion over properly setting
up what Xen and dom0 use for console devices.

Is anybody actively working on changes in this area?

As a simple first step I'm thinking of just adding a hypervisor
capability that tells dom0 which device the hypervisor
is using for a console.

Joe

Re: better console support

[Keir Fraser]

On 25/1/07 17:00, "Joe Bonasera" <joe.bonasera@sun.com> wrote:

> There seems to be a some confusion over properly setting
> up what Xen and dom0 use for console devices.
> 
> Is anybody actively working on changes in this area?

I'm not sure there's any confusion. By default Xen uses the VGA console
until dom0 starts executing, at which point it gives it up. At that point
Xen has no console devices. If the user overrides any settings, for example
to give Xen com1 then we make efforts to prevent dom0 from conflicting
(e.g., by silently disallowing its attempts to mess with com1).

 -- Keir

Re: better console support

[Joe Bonasera]

Keir Fraser wrote:
> On 25/1/07 17:00, "Joe Bonasera" <joe.bonasera@sun.com> wrote:
> 
>> There seems to be a some confusion over properly setting
>> up what Xen and dom0 use for console devices.
>>
>> Is anybody actively working on changes in this area?
> 
> I'm not sure there's any confusion. By default Xen uses the VGA console
> until dom0 starts executing, at which point it gives it up. At that point
> Xen has no console devices. If the user overrides any settings, for example
> to give Xen com1 then we make efforts to prevent dom0 from conflicting
> (e.g., by silently disallowing its attempts to mess with com1).
> 
>  -- Keir
> 

The silently disallowing thing, as well as the vga vs. vga all the time
is what is causing Solaris users confusion.

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.

The algorithm I'm envisioning is something like:
	hyper_cons_dev = ... /* from Xen capabilites, one of
				com1, com2, vga, or vgakeep */

	dom0_cons_dev = ... /* from dom0 command line, one of
			com1, com2, vga, or hypervisor --
			where hypervisor means use the
			HYPERVISOR_console_io() calls */

then in our dom0 startup we could do something like :

	if (hyper_cons_dev is vgakeep)
		if (dom0_cons_dev is vga)
			set dom0_cons_dev = hypervisor
		endif
	else if (hyper_cons_dev is vga)
		/* should just work */
	else if (hyper_cons_dev is same as dom0_cons_dev)
		set dom0_cons_dev = hypervisor
	endif

If that's a non-issue for Linux that's ok, it could
just ignore the new capability.

Joe



	

Re: better console support

[Keir Fraser]

On 25/1/07 18:47, "Joe Bonasera" <joe.bonasera@sun.com> 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.

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

 -- Keir

Re: better console support

[Edward Pilatowicz]

On Thu, Jan 25, 2007 at 06:55:29PM +0000, Keir Fraser wrote:
> On 25/1/07 18:47, "Joe Bonasera" <joe.bonasera@sun.com> 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.

Re: better console support

[Keir Fraser]

On 26/1/07 12:58 am, "Edward Pilatowicz" <edward.pilatowicz@sun.com> wrote:

> 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.

You could set up a remote debug session, but that's not really a normal
usage.

> 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.

Our observation has been that, as long as Linux keeps the console in text
mode (doesn't switch to X for example) we can let Linux think it owns the
VGA console and things don't screw up if Xen continues to have at it also.
Again, this isn't really something we'd consider as a normal usage scenario
-- more something to try if Xen doesn't boot and you can't connect a serial
line for some reason.

Xen doesn't include a full debugger -- it has a serial gdbstub which does
its job quite nicely -- so there's nothing really to plumb keyboard input
into. The set of 'debug keys' we plan to make accessible via the xm tool.

 -- Keir

Re: better console support

[John Levon]

On Fri, Jan 26, 2007 at 09:33:55AM +0000, Keir Fraser wrote:

> Xen doesn't include a full debugger

There is one out there though... maybe Christopher has thought about
this?

regards
john

Re: better console support

[Christoph Egger]

On Friday 26 January 2007 11:29, John Levon wrote:
> On Fri, Jan 26, 2007 at 09:33:55AM +0000, Keir Fraser wrote:
> > Xen doesn't include a full debugger
>
> There is one out there though... maybe Christopher has thought about
> this?

I have a working one. Is there a chance to get the patches into Xen 3.0.6 ?

Christoph

Re: better console support

[Keir Fraser]

On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

>>> Xen doesn't include a full debugger
>> 
>> There is one out there though... maybe Christopher has thought about
>> this?
> 
> I have a working one. Is there a chance to get the patches into Xen 3.0.6 ?

Why would anyone want to debug over a low-res unscrollable VGA console? If
you have a serial line connected then you can already debug via gdb, which
surely provides a nicer environment?

 -- Keir

Re: better console support

[Jan Beulich]

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 26.01.07 14:11 >>>
>On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>
>>>> Xen doesn't include a full debugger
>>> 
>>> There is one out there though... maybe Christopher has thought about
>>> this?
>> 
>> I have a working one. Is there a chance to get the patches into Xen 3.0.6 ?
>
>Why would anyone want to debug over a low-res unscrollable VGA console? If
>you have a serial line connected then you can already debug via gdb, which
>surely provides a nicer environment?

This really depends on what you're used to. I have a really hard time using
these scrolling interfaces (I constantly find myself re-typing commands or
scrolling back to see the information I just had on the screen, but that
scrolled off). This is also why, on the Linux side, I wanted what now is
called nlkd (and I was long planning to move this over to Xen, too, but I'm
simply not given time to do so).

Jan

Re: better console support

[Keir Fraser]

On 26/1/07 1:50 pm, "Jan Beulich" <jbeulich@novell.com> wrote:

>> Why would anyone want to debug over a low-res unscrollable VGA console? If
>> you have a serial line connected then you can already debug via gdb, which
>> surely provides a nicer environment?
> 
> This really depends on what you're used to. I have a really hard time using
> these scrolling interfaces (I constantly find myself re-typing commands or
> scrolling back to see the information I just had on the screen, but that
> scrolled off). This is also why, on the Linux side, I wanted what now is
> called nlkd (and I was long planning to move this over to Xen, too, but I'm
> simply not given time to do so).

That's pretty cool. Of course, you could build an old-school
all-in-one-screen debugging client talking to a gdbstub backend. Even if
incorporating into the kernel image itself, the debugger source code can
presumably be maintained separately quite easily (even in a separate
repository)? It ought to lend itself to acting as a very separate module
quite easily, since it effectively defines a separate execution mode for the
CPUs.

 -- Keir

Re: better console support

[Joe Bonasera]

Keir Fraser wrote:
> On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> 
>>>> Xen doesn't include a full debugger
>>> There is one out there though... maybe Christopher has thought about
>>> this?
>> I have a working one. Is there a chance to get the patches into Xen 3.0.6 ?
> 
> Why would anyone want to debug over a low-res unscrollable VGA console? If
> you have a serial line connected then you can already debug via gdb, which
> surely provides a nicer environment?
> 

It's not so much a choice of wanting to, as having to. Many classes of x86
computers no longer have serial ports. They're next to impossible to find on new
laptops and rapidly getting that way with desktops and workstations.
The people defining "platforms" have been killing off "legacy" devices like
serial ports in favor of USB. It's a lot easier to do a little VGA debugging than
to convince someone to go out and shop around for some sort of add in card
to get a serial port.

Joe

Re: better console support

[Edward Pilatowicz]

so it seems that some people are at least interested in accessing
the xen debugger on the local vga console keyboard.

so what would be any requirements for local console debugger support on
xen?

- would it be good to have access to vga/keyboard devices while xen is
  loading?  i guess this would depend on if xen currently support dropping
  to it's interactive debugger while it is booting up?  or only after the
  host os is booted?

- would it be sufficient to only be able to access the xen debugger
  via a vga/keyboard device after the dom0 os has started up?  if
  so would this be needed very early on in the dom0's boot or
  later on after the dom0 has had more time to bring itself up.

i'm really haven't had a huge amount of experience using the xen debugger
so i'm not sure what the most common use cases in the past have been.
answers to the questions above from people who have used the xen
debugger more extensively would be enlightening.

ed

On Fri, Jan 26, 2007 at 08:01:40AM -0800, Joe Bonasera wrote:
> Keir Fraser wrote:
> >On 26/1/07 12:54 pm, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> >
> >>>>Xen doesn't include a full debugger
> >>>There is one out there though... maybe Christopher has thought about
> >>>this?
> >>I have a working one. Is there a chance to get the patches into Xen 3.0.6
> >>?
> >
> >Why would anyone want to debug over a low-res unscrollable VGA console? If
> >you have a serial line connected then you can already debug via gdb, which
> >surely provides a nicer environment?
> >
>
> It's not so much a choice of wanting to, as having to. Many classes of x86
> computers no longer have serial ports. They're next to impossible to find
> on new
> laptops and rapidly getting that way with desktops and workstations.
> The people defining "platforms" have been killing off "legacy" devices like
> serial ports in favor of USB. It's a lot easier to do a little VGA
> debugging than
> to convince someone to go out and shop around for some sort of add in card
> to get a serial port.
>
> Joe
>