Xen virtual console driver question

I am currently using the below patch, but would really prefer not to. It's basic approach is to have the Xen virtual console driver react "gracefully" in the case that a real serial driver has already registered ttyS0-ttyS3. It's current behavior is to fail if the 8250 driver was initialized ahead of it, and console is lost. In the process I found a bug in Linux, and have included the patch for it since otherwise the Xen driver initialization will succeed but with negative side effects in the kobject subsystem.

What is the story?

Quoted 9 lines · Amos Waterland

I am currently using the below patch, but would really prefer not to. It's basic approach is to have the Xen virtual console driver react "gracefully" in the case that a real serial driver has already registered ttyS0-ttyS3. It's current behavior is to fail if the 8250 driver was initialized ahead of it, and console is lost. In the process I found a bug in Linux, and have included the patch for it since otherwise the Xen driver initialization will succeed but with negative side effects in the kobject subsystem.

Quoted 1 line

What is the story?

We need to obtain our own device number and then patch the driver. It'd be great if someone else wants to look into this.

-- Keir

The below is the least invasive approach I can find, and works well on my PPC64 blades: I can boot the exact same kernel on bare hardware and as a dom0. I am sure there will be distro concerns (such as /etc/inittab and /etc/securetty), but I'd like to get the ball rolling with this initial submission.

Note that you have to put xencons=xvc0' in your Linux .config, and run mknod /dev/xvc0 c 232 0' in your rootfs.

Signed-off-by Amos Waterland <[email protected]>

Quoted 9 lines · Amos Waterland

The below is the least invasive approach I can find, and works well on my PPC64 blades: I can boot the exact same kernel on bare hardware and as a dom0. I am sure there will be distro concerns (such as /etc/inittab and /etc/securetty), but I'd like to get the ball rolling with this initial submission.

Note that you have to put xencons=xvc0' in your Linux .config, and run mknod /dev/xvc0 c 232 0' in your rootfs.

Quoted 1 line

Signed-off-by Amos Waterland <[email protected]>

How did you pick the major? Is there a process for allocating one (I think our bklock-device major is now official)? Could we use a more dynamic (e.g., udev-based) scheme to avoid locking down 1/256th of the 8-bit major space for this?

Quoted 4 lines

How did you pick the major? Is there a process for allocating one (I think our bklock-device major is now official)? Could we use a more dynamic (e.g., udev-based) scheme to avoid locking down 1/256th of the 8-bit major space for this?

The instructions for getting a major are available at
http://www.lanana.org/docs/device-list/instructions.txt and the official list of majors/minors is at
http://www.lanana.org/docs/device-list/devices-2.6+.txt.

char major 232 is already taken for biometrics. There's no reason that we shouldn't be able to get a minor (or a couple, if it makes more sense to have more than one xvc device in some case) char devices in the low-density serial console region (char major 204)

Quoted 10 lines · Jeremy Katz

Quoted 4 lines

How did you pick the major? Is there a process for allocating one (I think our bklock-device major is now official)? Could we use a more dynamic (e.g., udev-based) scheme to avoid locking down 1/256th of the 8-bit major space for this?

The instructions for getting a major are available at
http://www.lanana.org/docs/device-list/instructions.txt and the official list of majors/minors is at
http://www.lanana.org/docs/device-list/devices-2.6+.txt.

Quoted 4 lines

char major 232 is already taken for biometrics. There's no reason that we shouldn't be able to get a minor (or a couple, if it makes more sense to have more than one xvc device in some case) char devices in the low-density serial console region (char major 204)

That page makes it sound like the static allocation of device numbers is obsolete. Is there some preferred dynamic method now?

Use the low-density serial console major and the next free minor according to the Lanana. Since it would be awkward to say 'xencons=xvc187', use name_base to allow /dev/xvc0 to be major/minor 204/187.

Quoted 4 lines · Amos Waterland

Use the low-density serial console major and the next free minor according to the Lanana. Since it would be awkward to say 'xencons=xvc187', use name_base to allow /dev/xvc0 to be major/minor 204/187.

Please go through the process of sending mail to lanana and getting an officially assigned number. Once that's done and it's being used, this should be okay but not before.

Quoted 3 lines

Please go through the process of sending mail to lanana and getting an officially assigned number. Once that's done and it's being used, this should be okay but not before.

I can send this to [email protected]. Keir, is this all right with you?

diff -r 17aa29a18b08 drivers/xen/console/console.c

drivers/xen/console/console.c +1 -0

@@ -63,13 +63,20 @@
  *  'xencons=off'  [XC_OFF]:     Console is disabled.
  *  'xencons=tty'  [XC_TTY]:     Console attached to '/dev/tty[0-9] 
+'.
  *  'xencons=ttyS' [XC_SERIAL]:  Console attached to '/dev/ttyS 

[0-9]+'.
+ * 'xencons=xvc' [XC_XVC]: Console attached to '/dev/xvc[0-9]
+'.
* [XC_DEFAULT]: DOM0 -> XC_SERIAL ; all others ->
XC_TTY.

Quoted 8 lines · Amos Waterland

diff -r 17aa29a18b08 drivers/xen/console/console.c

drivers/xen/console/console.c +1 -0

@@ -63,13 +63,20 @@
  *  'xencons=off'  [XC_OFF]:     Console is disabled.
  *  'xencons=tty'  [XC_TTY]:     Console attached to '/dev/tty[0-9] 
+'.
  *  'xencons=ttyS' [XC_SERIAL]:  Console attached to '/dev/ttyS 

Quoted 5 lines

[0-9]+'.
+ * 'xencons=xvc' [XC_XVC]: Console attached to '/dev/xvc[0-9]
+'.
* [XC_DEFAULT]: DOM0 -> XC_SERIAL ; all others ->
XC_TTY.

Can't we switch the DomU's to XVC as well?

Quoted 8 lines

diff -r 17aa29a18b08 drivers/xen/console/console.c

drivers/xen/console/console.c Fri Aug 04 13:04:06 2006 -0400 renamed from drivers/xen/console/console.c Thu Jul 27 18:57:20 2006 -0400 +1 -0

@@ -63,13 +63,20 @@
  *  'xencons=off'  [XC_OFF]:     Console is disabled.
  *  'xencons=tty'  [XC_TTY]:     Console attached to '/dev/tty[0-9]
+'.
  *  'xencons=ttyS' [XC_SERIAL]:  Console attached to '/dev/ttyS

Quoted 5 lines

[0-9]+'.
+ * 'xencons=xvc' [XC_XVC]: Console attached to '/dev/xvc[0-9]
+'.
* [XC_DEFAULT]: DOM0 -> XC_SERIAL ; all others ->
XC_TTY.

Can't we switch the DomU's to XVC as well?

Use the low-density serial console major and the next free minor according to the Lanana. Since it would be awkward to say 'xencons=xvc187', use name_base to allow /dev/xvc0 to be major/minor 204/187.

To use, put xencons=xvc0' in your Linux .config, and run mknod /dev/xvc0 c 204 187' in your rootfs. Built and booted up to nfsroot on a JS21 ppc64 blade both on bare hardware and as a dom0.

Signed-off-by Amos Waterland <[email protected]>

The below is the least invasive approach I can find, and works well on my PPC64 blades: I can boot the exact same kernel on bare hardware and as a dom0. I am sure there will be distro concerns (such as /etc/inittab and /etc/securetty), but I'd like to get the ball rolling with this initial submission.