[PATCH 0/2] A couple of workarounds for Xen based VPS services

[PATCH 0/2] A couple of workarounds for Xen based VPS services

[Soren Hansen]

Several Xen based VPS providers (Rackspace Cloud Servers, Slicehost,
and Amazon EC2 just to name a few) are faced with (at least :) ) two
problems with the current Xen support in the kernel.

Mostly, these problems stem from the fact that there are many different
guest distro's with very different levels of flexibility in terms of
being able to find its root device and in terms of being able to use an
hvc based console.

1. Most, if not all (because that's how the infrastructure has presented
   things so far) expect to find their root device on (a partition on)
   /dev/sda. However, without a patch to the current kernel, Xen block
   devices will turn up as /dev/xvda.

2. Very few of the guest systems know to use hvc0 as its console if its
   available. Instead of requiring all the guests to be changed, it's
   simpler to just make any attempt to talk to /dev/tty1 actually talk
   to hvc0.

These two patches add two new configuratin options that lets you work
around these problems. Enjoy.

Soren Hansen (2):
  Allow hvc tty's to pose as vt's
  Make the Xen block device prefix configurable

 drivers/block/Kconfig        |   10 ++++++++++
 drivers/block/xen-blkfront.c |    2 +-
 drivers/char/Kconfig         |    9 ++++++++-
 drivers/char/hvc_console.c   |    9 +++++++++
 4 files changed, 28 insertions(+), 2 deletions(-)

[PATCH 1/2] Allow hvc tty's to pose as vt's

[Soren Hansen]

Allow for hvc based tty's to take over the vt driver's major number
and namespace.

Signed-off-by: Soren Hansen <soren@linux2go.dk>
Tested-By: Major Hayden <major.hayden@rackspace.com>

---
 drivers/char/Kconfig       |    9 ++++++++-
 drivers/char/hvc_console.c |    9 +++++++++
 2 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 6aad99e..8610179 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -5,7 +5,7 @@
 menu "Character devices"
 
 config VT
-	bool "Virtual terminal" if EMBEDDED
+	bool "Virtual terminal"
 	depends on !S390
 	select INPUT
 	default y
@@ -602,6 +602,13 @@ config PPDEV
 
 	  If unsure, say N.
 
+config HVC_TTY_HACK
+	bool "Apply various hacks to make hvc[0-] pretend to be tty[1-]"
+	depends on !VT
+	help
+	  Make unsuspecting guests work happily with the hvc concoles by
+	  tricking them into thinking they're plain old ttys.
+
 config HVC_DRIVER
 	bool
 	help
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index a632f25..4c6b03d 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -43,7 +43,11 @@
 
 #include "hvc_console.h"
 
+#ifdef CONFIG_HVC_TTY_HACK
+#define HVC_MAJOR	4
+#else /* CONFIG_HVC_TTY_HACK */
 #define HVC_MAJOR	229
+#endif /* CONFIG_HVC_TTY_HACK */
 #define HVC_MINOR	0
 
 /*
@@ -848,7 +852,12 @@ static int hvc_init(void)
 
 	drv->owner = THIS_MODULE;
 	drv->driver_name = "hvc";
+#ifdef CONFIG_HVC_TTY_HACK
+	drv->name = "tty";
+	drv->name_base = 1;
+#else /* CONFIG_HVC_TTY_HACK */
 	drv->name = "hvc";
+#endif /* CONFIG_HVC_TTY_HACK */
 	drv->major = HVC_MAJOR;
 	drv->minor_start = HVC_MINOR;
 	drv->type = TTY_DRIVER_TYPE_SYSTEM;
-- 
1.7.0.4

Re: [PATCH 1/2] Allow hvc tty's to pose as vt's

[Alan Cox]

On Fri, 14 May 2010 18:10:12 +0200
Soren Hansen <soren@linux2go.dk> wrote:

> Allow for hvc based tty's to take over the vt driver's major number
> and namespace.

We've got a perfect good udev and symlink functionality to
rename devices in userspace.

NAK.

I can see why its useful as a hack in a specific user environment but its
not appropriate for upstream.

Re: [PATCH 1/2] Allow hvc tty's to pose as vt's

[Soren Hansen]

On Fri, May 14, 2010 at 05:43:48PM +0100, Alan Cox wrote:
>> Allow for hvc based tty's to take over the vt driver's major number
>> and namespace.
> We've got a perfect good udev and symlink functionality to rename
> devices in userspace.

I agree in principle. The reason this really is necessary for us
(Rackspace) is that we have tons of customers running tons and tons of
these virtual machines, and we can't (well, of course we /could/, but
that'd be horrible) go around and change people's virtual machines to
accomodate changes we want to make on the hypervisor side.

> NAK.

Fair enough. I really just wanted to share it in case someone else would
find it useful.

-- 
Soren Hansen
System Architect, The Rackspace Cloud
Ubuntu Developer

Re: [PATCH 1/2] Allow hvc tty's to pose as vt's

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On Fri, 14 May 2010 18:10:12 +0200, Soren Hansen said:
> Allow for hvc based tty's to take over the vt driver's major number
> and namespace.

> +#ifdef CONFIG_HVC_TTY_HACK
> +#define HVC_MAJOR	4
> +#else /* CONFIG_HVC_TTY_HACK */
>  #define HVC_MAJOR	229
> +#endif /* CONFIG_HVC_TTY_HACK */
>  #define HVC_MINOR	0

Out of curiosity, what happens if you boot a kernel with this config hack
on a system that has real live "plain old ttys"?

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

[PATCH 2/2] Make the Xen block device prefix configurable

[Soren Hansen]

Add a config option to tweak the Xen block device prefix.

Signed-off-by: Soren Hansen <soren@linux2go.dk>
Tested-By: Major Hayden <major.hayden@rackspace.com>
---
 drivers/block/Kconfig        |   10 ++++++++++
 drivers/block/xen-blkfront.c |    2 +-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 1d886e0..89c1887 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -467,6 +467,16 @@ config XEN_BLKDEV_FRONTEND
 	  block device driver.  It communicates with a back-end driver
 	  in another domain which drives the actual block device.
 
+config XEN_BLKDEV_NAME
+	string "Base name for Xen block devices"
+	depends on XEN_BLKDEV_FRONTEND
+	default "xvd"
+	help
+	  Use this as the base name for Xen block devices. This is
+	  traditionally "xvd", but if you're trying to boot a system
+	  that expects to find its root device on /dev/sda, you can
+	  use this setting to accomodate that.
+
 config VIRTIO_BLK
 	tristate "Virtio block driver (EXPERIMENTAL)"
 	depends on EXPERIMENTAL && VIRTIO
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index b8578bb..a8fd8fd 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -117,7 +117,7 @@ static DEFINE_SPINLOCK(blkif_io_lock);
 #define VDEV_IS_EXTENDED(dev) ((dev)&(EXTENDED))
 #define BLKIF_MINOR_EXT(dev) ((dev)&(~EXTENDED))
 
-#define DEV_NAME	"xvd"	/* name in /dev */
+#define DEV_NAME CONFIG_XEN_BLKDEV_NAME /* name in /dev */
 
 static int get_id_from_freelist(struct blkfront_info *info)
 {
-- 
1.7.0.4

Re: [PATCH 2/2] Make the Xen block device prefix configurable

[Randy Dunlap]

On Fri, 14 May 2010 18:10:48 +0200 Soren Hansen wrote:

> Add a config option to tweak the Xen block device prefix.
> 
> Signed-off-by: Soren Hansen <soren@linux2go.dk>
> Tested-By: Major Hayden <major.hayden@rackspace.com>
> ---
>  drivers/block/Kconfig        |   10 ++++++++++
>  drivers/block/xen-blkfront.c |    2 +-
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 1d886e0..89c1887 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -467,6 +467,16 @@ config XEN_BLKDEV_FRONTEND
>  	  block device driver.  It communicates with a back-end driver
>  	  in another domain which drives the actual block device.
>  
> +config XEN_BLKDEV_NAME
> +	string "Base name for Xen block devices"
> +	depends on XEN_BLKDEV_FRONTEND
> +	default "xvd"
> +	help
> +	  Use this as the base name for Xen block devices. This is
> +	  traditionally "xvd", but if you're trying to boot a system
> +	  that expects to find its root device on /dev/sda, you can
> +	  use this setting to accomodate that.

	                      accommodate

> +
>  config VIRTIO_BLK
>  	tristate "Virtio block driver (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && VIRTIO


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***