RE: [Xen-devel] xen console question

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

>    With a few recent changes, we have the console working 
> pretty well on the xen/ia64 port.  However, we're trying to 
> come to grips with the xen0/U config file implication of 
> xencons_driver.  It seems the xen0 config file cannot include 
> CONFIG_SERIAL_8250 since the default console for that domain 
> is a serial device.  Likewise xenU cannot include CONFIG_VT 
> because those domains default to tty devices.  In both cases 
> the call to tty_register_driver() overlaps with major/minor 
> number for the in-kernel drivers and therefore cannot co-exist.

Yep, it would be good to have a standard xen console device in the same
way we now have xvdX. We actually probably want a range to allow for
multiple consoles.
 
>    What can we do to fix this?  I assume these devices were 
> chosen for compatibility, but on ia64 we'd ideally like to be 
> able to boot kernels with generic config files that work 
> either on bare metal or xen.  I don't know if we should try 
> to standardize something like a "ttyXen"
> device or if there's some more obscure device we could piggy back on.
> Any thoughts on where we might go with this?  I assume there 
> are some people out there that would like to use physical 
> 8250 UART ports w/ a xen0 kernel if nothing else.  Thanks,

I've appended my checkin message from when I last made changes in this
area.
Best,
Ian



bitkeeper revision 1.1236.42.1 (42422fb2SvqEyBwXAZf3p2BJS-gfBA)

If Xen is told to use a serial console via a com1= or com2= directive
on the Xen command line, it now hides that particular UART from dom0.

This means that it's now safe to enable the 8250 driver in the Linux
config. If Xen has been told to use com1, the dom0 linux kernel will
not see /dev/ttyS0, but will see ttyS1,S2 etc if they are present,
enabling them to be used for mice, modems, printers etc.

Unfortunately, the 8250 driver will register itself for a ttyS even if
that particular UART isn't present. This is really annoying, as it
prevents the 'xencons' driver registering itself as ttyS0 even though
the 8250 won't see ttyS0 as present if Xen is using com1. This
prevents us from enabling 8250 in the default kernel config, as it
will change current behaviour.

If you want to use 8250 and xencons, the trick is to tell xencons to
grab a high numbered ttyS port that the 8250 driver will have left
alone. For example, put "xencons=ttyS31" on the Linux command line.
You'll then be able to edit /etc/inittab to add an entry for a
getty on ttyS31 if you want to be able to log in on the serial console
that is being shared with Xen.

If anyone knows a way of cleanly kicking the 8250 driver off a
particular char minor then please let me know!

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