When is the next version of xen is supposed to be released?

When is the next version of xen is supposed to be released?

[Tom Rotenberg]

Hi all,

does anyone know when will the next xen version be released?
Also, does anyone know which features/fixes thsi feature will contain?

Tom

Re: When is the next version of xen is supposed to be released?

[Keir Fraser]

On 15/10/2009 11:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote:

> does anyone know when will the next xen version be released?

January most likely.

> Also, does anyone know which features/fixes thsi feature will contain?

Whatever is stabilised in the xen-unstable repository by then. :-)

netchannel2, some form of ha solution hopefully, gdbsx guest debugger, Dan
Magenheimer's emulated TSC stuff, guest page sharing (possibly), new
scheduler (possibly), ...

 -- Keir

Re: When is the next version of xen is supposed to be released?

[Pasi Kärkkäinen]

On Thu, Oct 15, 2009 at 12:25:35PM +0100, Keir Fraser wrote:
> On 15/10/2009 11:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote:
> 
> > does anyone know when will the next xen version be released?
> 
> January most likely.
> 
> > Also, does anyone know which features/fixes thsi feature will contain?
> 
> Whatever is stabilised in the xen-unstable repository by then. :-)
> 
> netchannel2, some form of ha solution hopefully, gdbsx guest debugger, Dan
> Magenheimer's emulated TSC stuff, guest page sharing (possibly), new
> scheduler (possibly), ...
> 

Will it be called Xen 4.0 ? :)

-- Pasi

Re: When is the next version of xen is supposed to be released?

[Keir Fraser]

On 15/10/2009 13:23, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:

>> Whatever is stabilised in the xen-unstable repository by then. :-)
>> 
>> netchannel2, some form of ha solution hopefully, gdbsx guest debugger, Dan
>> Magenheimer's emulated TSC stuff, guest page sharing (possibly), new
>> scheduler (possibly), ...
>> 
> 
> Will it be called Xen 4.0 ? :)

It might well be. It's not 100% decided yet.

 -- Keir

Re: When is the next version of xen is supposed to be released?

[Joshua West]

Hey Keir,

Can you elaborate on the HA solution?  Will this be something like
Kemari, included with Xen, or something completely new?

And by guest page sharing, this means memory overprovisioning/committing
instead of the balloon driver automation from Oracle/Dan?

Lastly, m/any changes to the XML-RPC Xen API?

Thanks!

Keir Fraser wrote:
> On 15/10/2009 11:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote:
>
>   
>> does anyone know when will the next xen version be released?
>>     
>
> January most likely.
>
>   
>> Also, does anyone know which features/fixes thsi feature will contain?
>>     
>
> Whatever is stabilised in the xen-unstable repository by then. :-)
>
> netchannel2, some form of ha solution hopefully, gdbsx guest debugger, Dan
> Magenheimer's emulated TSC stuff, guest page sharing (possibly), new
> scheduler (possibly), ...
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   


-- 
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu

Re: When is the next version of xen is supposed to be released?

[Keir Fraser]

On 15/10/2009 16:51, "Joshua West" <jwest@brandeis.edu> wrote:

> Can you elaborate on the HA solution?  Will this be something like
> Kemari, included with Xen, or something completely new?

Kemari or Remus.

> And by guest page sharing, this means memory overprovisioning/committing
> instead of the balloon driver automation from Oracle/Dan?

Yes. It's in progress, but no definite completion date yet.

> Lastly, m/any changes to the XML-RPC Xen API?

I doubt it. Is anyone seriously working on that any more?

 -- Keir

Re: When is the next version of xen is supposed to be released?

[Joshua West]

Keir Fraser wrote:
> On 15/10/2009 16:51, "Joshua West" <jwest@brandeis.edu> wrote:
>
>   
>> Can you elaborate on the HA solution?  Will this be something like
>> Kemari, included with Xen, or something completely new?
>>     
>
> Kemari or Remus.
>   

Awesome -- both good projects.

>> Lastly, m/any changes to the XML-RPC Xen API?
>>     
>
> I doubt it. Is anyone seriously working on that any more?
>   

The API is pretty complete, so beyond simple extensions or bug fixes, I
wouldn't think anybody would even need to.  Either way though, just as
long as it doesn't change (much), I'll stay happy as I've been working
quite a bit with it :-)

One other question -- any thoughts on when 3.4.2 will be released?

Thanks for the info on what we may see in the next version.

-- 
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu

Re: When is the next version of xen is supposed to be released?

[Keir Fraser]

On 15/10/2009 17:06, "Joshua West" <jwest@brandeis.edu> wrote:

>> I doubt it. Is anyone seriously working on that any more?
>>   
> 
> The API is pretty complete, so beyond simple extensions or bug fixes, I
> wouldn't think anybody would even need to.  Either way though, just as
> long as it doesn't change (much), I'll stay happy as I've been working
> quite a bit with it :-)
> 
> One other question -- any thoughts on when 3.4.2 will be released?

It's about time to tag an rc for that. I'll look into it next week.

 -- Keir

Re: [PATCH] pv bootloader support for bzip2/lzma compressed kernels for Xen 3.4.2

[Pasi Kärkkäinen]

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

On Thu, Oct 15, 2009 at 05:14:22PM +0100, Keir Fraser wrote:
> On 15/10/2009 17:06, "Joshua West" <jwest@brandeis.edu> wrote:
> 
> >> I doubt it. Is anyone seriously working on that any more?
> >>   
> > 
> > The API is pretty complete, so beyond simple extensions or bug fixes, I
> > wouldn't think anybody would even need to.  Either way though, just as
> > long as it doesn't change (much), I'll stay happy as I've been working
> > quite a bit with it :-)
> > 
> > One other question -- any thoughts on when 3.4.2 will be released?
> 
> It's about time to tag an rc for that. I'll look into it next week.
> 

Keir: Please include the attached bzip2/lzma pv bootloader patch to Xen 3.4-testing for 3.4.2.

It's a backport from xen-unstable. It's included in Fedora 12/rawhide
Xen rpms and seems to work OK. No pvgrub (stubdom) support yet.

-- Pasi


[-- Attachment #2: xen-341-add-bzip2-lzma-pv-bootloader-support-v2-no-stubdom-pvgrub.patch --]
[-- Type: text/x-diff, Size: 13523 bytes --]

--- xen-3.4-testing.hg/tools/libxc/Makefile	2009-09-01 17:19:44.000000000 +0300
+++ xen-unstable.hg/tools/libxc/Makefile	2009-09-01 17:12:45.000000000 +0300
@@ -149,6 +151,25 @@
 libxenguest.so.$(MAJOR): libxenguest.so.$(MAJOR).$(MINOR)
 	ln -sf $< $@
 
+ifeq ($(CONFIG_MiniOS),y)
+zlib-options =
+else
+zlib-options = $(shell					\
+	(. ../check/funcs.sh;				\
+	 if has_header bzlib.h; then			\
+           echo "-DHAVE_BZLIB";				\
+	   echo "-lbz2";				\
+	 fi;						\
+	 if has_header lzma.h; then			\
+	   echo "-DHAVE_LZMA";				\
+	   echo "-llzma";				\
+	 fi) | grep $(1))
+endif
+
+xc_dom_bzimageloader.o: CFLAGS += $(call zlib-options,D)
+xc_dom_bzimageloader.opic: CFLAGS += $(call zlib-options,D)
+
+libxenguest.so.$(MAJOR).$(MINOR): LDFLAGS += $(call zlib-options,l)
 libxenguest.so.$(MAJOR).$(MINOR): $(GUEST_PIC_OBJS) libxenctrl.so
 	$(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenguest.so.$(MAJOR) $(SHLIB_CFLAGS) -o $@ $(GUEST_PIC_OBJS) -lz -lxenctrl $(PTHREAD_LIBS)
 
--- xen-3.4-testing.hg/tools/libxc/xc_dom_bzimageloader.c	2009-09-01 17:19:44.000000000 +0300
+++ xen-unstable.hg/tools/libxc/xc_dom_bzimageloader.c	2009-09-01 17:12:45.000000000 +0300
@@ -11,6 +11,7 @@
  * written 2006 by Gerd Hoffmann <kraxel@suse.de>.
  * written 2007 by Jeremy Fitzhardinge <jeremy@xensource.com>
  * written 2008 by Ian Campbell <ijc@hellion.org.uk>
+ * written 2009 by Chris Lalancette <clalance@redhat.com>
  *
  */
 #include <stdio.h>
@@ -20,43 +21,289 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
+#if defined(HAVE_BZLIB)
+
+#include <bzlib.h>
+
+static int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    bz_stream stream;
+    int ret;
+    char *out_buf;
+    int retval = -1;
+    int outsize;
+    uint64_t total;
+
+    stream.bzalloc = NULL;
+    stream.bzfree = NULL;
+    stream.opaque = NULL;
+
+    ret = BZ2_bzDecompressInit(&stream, 0, 0);
+    if ( ret != BZ_OK )
+    {
+        xc_dom_printf("Error initting bz2 stream\n");
+        return -1;
+    }
+
+    /* sigh.  We don't know up-front how much memory we are going to need
+     * for the output buffer.  Allocate the output buffer to be equal
+     * the input buffer to start, and we'll realloc as needed.
+     */
+    outsize = dom->kernel_size;
+    out_buf = malloc(outsize);
+    if ( out_buf == NULL )
+    {
+        xc_dom_printf("Failed to alloc memory\n");
+        goto bzip2_cleanup;
+    }
+
+    stream.next_in = dom->kernel_blob;
+    stream.avail_in = dom->kernel_size;
+
+    stream.next_out = out_buf;
+    stream.avail_out = dom->kernel_size;
+
+    for ( ; ; )
+    {
+        ret = BZ2_bzDecompress(&stream);
+        if ( (stream.avail_out == 0) || (ret != BZ_OK) )
+        {
+            out_buf = realloc(out_buf, outsize * 2);
+            if ( out_buf == NULL )
+            {
+                xc_dom_printf("Failed to realloc memory\n");
+                break;
+            }
+
+            stream.next_out = out_buf + outsize;
+            stream.avail_out = (outsize * 2) - outsize;
+            outsize *= 2;
+        }
+
+        if ( ret != BZ_OK )
+        {
+            if ( ret == BZ_STREAM_END )
+            {
+                xc_dom_printf("Saw data stream end\n");
+                retval = 0;
+                break;
+            }
+            xc_dom_printf("BZIP error\n");
+        }
+    }
+
+    total = (stream.total_out_hi32 << 31) | stream.total_out_lo32;
+
+    xc_dom_printf("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx\n",
+                  __FUNCTION__, *size, (long unsigned int) total);
+
+    *blob = out_buf;
+    *size = total;
+
+ bzip2_cleanup:
+    BZ2_bzDecompressEnd(&stream);
+
+    return retval;
+}
+
+#else /* !defined(HAVE_BZLIB) */
+
+static int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    xc_dom_printf("%s: BZIP2 decompress support unavailable\n",
+                  __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+#if defined(HAVE_LZMA)
+
+#include <lzma.h>
+
+static uint64_t physmem(void)
+{
+    uint64_t ret = 0;
+    const long pagesize = sysconf(_SC_PAGESIZE);
+    const long pages = sysconf(_SC_PHYS_PAGES);
+
+    if ( (pagesize != -1) || (pages != -1) )
+    {
+        /*
+         * According to docs, pagesize * pages can overflow.
+         * Simple case is 32-bit box with 4 GiB or more RAM,
+         * which may report exactly 4 GiB of RAM, and "long"
+         * being 32-bit will overflow. Casting to uint64_t
+         * hopefully avoids overflows in the near future.
+         */
+        ret = (uint64_t)(pagesize) * (uint64_t)(pages);
+    }
+
+    return ret;
+}
+
+static int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    lzma_stream stream = LZMA_STREAM_INIT;
+    lzma_ret ret;
+    lzma_action action = LZMA_RUN;
+    unsigned char *out_buf;
+    int retval = -1;
+    int outsize;
+    const char *msg;
+
+    ret = lzma_alone_decoder(&stream, physmem() / 3);
+    if ( ret != LZMA_OK )
+    {
+        xc_dom_printf("Failed to init lzma stream decoder\n");
+        return -1;
+    }
+
+    /* sigh.  We don't know up-front how much memory we are going to need
+     * for the output buffer.  Allocate the output buffer to be equal
+     * the input buffer to start, and we'll realloc as needed.
+     */
+    outsize = dom->kernel_size;
+    out_buf = malloc(outsize);
+    if ( out_buf == NULL )
+    {
+        xc_dom_printf("Failed to alloc memory\n");
+        goto lzma_cleanup;
+    }
+
+    stream.next_in = dom->kernel_blob;
+    stream.avail_in = dom->kernel_size;
+
+    stream.next_out = out_buf;
+    stream.avail_out = dom->kernel_size;
+
+    for ( ; ; )
+    {
+        ret = lzma_code(&stream, action);
+        if ( (stream.avail_out == 0) || (ret != LZMA_OK) )
+        {
+            out_buf = realloc(out_buf, outsize * 2);
+            if ( out_buf == NULL )
+            {
+                xc_dom_printf("Failed to realloc memory\n");
+                break;
+            }
+
+            stream.next_out = out_buf + outsize;
+            stream.avail_out = (outsize * 2) - outsize;
+            outsize *= 2;
+        }
+
+        if ( ret != LZMA_OK )
+        {
+            if ( ret == LZMA_STREAM_END )
+            {
+                xc_dom_printf("Saw data stream end\n");
+                retval = 0;
+                break;
+            }
+
+            switch ( ret )
+            {
+            case LZMA_MEM_ERROR:
+                msg = strerror(ENOMEM);
+                break;
+
+            case LZMA_MEMLIMIT_ERROR:
+                msg = "Memory usage limit reached";
+                break;
+
+            case LZMA_FORMAT_ERROR:
+                msg = "File format not recognized";
+                break;
+
+            case LZMA_OPTIONS_ERROR:
+                // FIXME: Better message?
+                msg = "Unsupported compression options";
+                break;
+
+            case LZMA_DATA_ERROR:
+                msg = "File is corrupt";
+                break;
+
+            case LZMA_BUF_ERROR:
+                msg = "Unexpected end of input";
+                break;
+
+            default:
+                msg = "Internal program error (bug)";
+                break;
+            }
+            xc_dom_printf("%s: LZMA decompression error %s\n",
+                          __FUNCTION__, msg);
+            break;
+        }
+    }
+
+    xc_dom_printf("%s: LZMA decompress OK, 0x%zx -> 0x%zx\n",
+                  __FUNCTION__, *size, (size_t)stream.total_out);
+
+    *blob = out_buf;
+    *size = stream.total_out;
+
+ lzma_cleanup:
+    lzma_end(&stream);
+
+    return retval;
+}
+
+#else /* !defined(HAVE_LZMA) */
+
+static int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    xc_dom_printf("%s: LZMA decompress support unavailable\n",
+                  __FUNCTION__);
+    return -1;
+}
+
+#endif
+
 struct setup_header {
-	uint8_t		_pad0[0x1f1];		/* skip uninteresting stuff */
-	uint8_t		setup_sects;
-	uint16_t	root_flags;
-	uint32_t	syssize;
-	uint16_t	ram_size;
-	uint16_t	vid_mode;
-	uint16_t	root_dev;
-	uint16_t	boot_flag;
-	uint16_t	jump;
-	uint32_t	header;
-#define HDR_MAGIC		"HdrS"
-#define HDR_MAGIC_SZ	4
-	uint16_t	version;
-#define VERSION(h,l)	(((h)<<8) | (l))
-	uint32_t	realmode_swtch;
-	uint16_t	start_sys;
-	uint16_t	kernel_version;
-	uint8_t		type_of_loader;
-	uint8_t		loadflags;
-	uint16_t	setup_move_size;
-	uint32_t	code32_start;
-	uint32_t	ramdisk_image;
-	uint32_t	ramdisk_size;
-	uint32_t	bootsect_kludge;
-	uint16_t	heap_end_ptr;
-	uint16_t	_pad1;
-	uint32_t	cmd_line_ptr;
-	uint32_t	initrd_addr_max;
-	uint32_t	kernel_alignment;
-	uint8_t		relocatable_kernel;
-	uint8_t		_pad2[3];
-	uint32_t	cmdline_size;
-	uint32_t	hardware_subarch;
-	uint64_t	hardware_subarch_data;
-	uint32_t	payload_offset;
-	uint32_t	payload_length;
+    uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
+    uint8_t  setup_sects;
+    uint16_t root_flags;
+    uint32_t syssize;
+    uint16_t ram_size;
+    uint16_t vid_mode;
+    uint16_t root_dev;
+    uint16_t boot_flag;
+    uint16_t jump;
+    uint32_t header;
+#define HDR_MAGIC  "HdrS"
+#define HDR_MAGIC_SZ 4
+    uint16_t version;
+#define VERSION(h,l) (((h)<<8) | (l))
+    uint32_t realmode_swtch;
+    uint16_t start_sys;
+    uint16_t kernel_version;
+    uint8_t  type_of_loader;
+    uint8_t  loadflags;
+    uint16_t setup_move_size;
+    uint32_t code32_start;
+    uint32_t ramdisk_image;
+    uint32_t ramdisk_size;
+    uint32_t bootsect_kludge;
+    uint16_t heap_end_ptr;
+    uint16_t _pad1;
+    uint32_t cmd_line_ptr;
+    uint32_t initrd_addr_max;
+    uint32_t kernel_alignment;
+    uint8_t  relocatable_kernel;
+    uint8_t  _pad2[3];
+    uint32_t cmdline_size;
+    uint32_t hardware_subarch;
+    uint64_t hardware_subarch_data;
+    uint32_t payload_offset;
+    uint32_t payload_length;
 } __attribute__((packed));
 
 extern struct xc_dom_loader elf_loader;
@@ -70,22 +317,22 @@
     return off;
 }
 
-static int check_bzimage_kernel(struct xc_dom_image *dom, int verbose)
+static int xc_dom_probe_bzimage_kernel(struct xc_dom_image *dom)
 {
     struct setup_header *hdr;
+    int ret;
 
     if ( dom->kernel_blob == NULL )
     {
-        if ( verbose )
-            xc_dom_panic(XC_INTERNAL_ERROR, "%s: no kernel image loaded\n",
-                         __FUNCTION__);
+        xc_dom_panic(XC_INTERNAL_ERROR, "%s: no kernel image loaded\n",
+                     __FUNCTION__);
         return -EINVAL;
     }
+
     if ( dom->kernel_size < sizeof(struct setup_header) )
     {
-        if ( verbose )
-            xc_dom_panic(XC_INTERNAL_ERROR, "%s: kernel image too small\n",
-                         __FUNCTION__);
+        xc_dom_panic(XC_INTERNAL_ERROR, "%s: kernel image too small\n",
+                     __FUNCTION__);
         return -EINVAL;
     }
 
@@ -93,39 +340,64 @@
 
     if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
     {
-        if ( verbose )
-            xc_dom_panic(XC_INVALID_KERNEL, "%s: kernel is not a bzImage\n",
-                         __FUNCTION__);
+        xc_dom_panic(XC_INVALID_KERNEL, "%s: kernel is not a bzImage\n",
+                     __FUNCTION__);
         return -EINVAL;
     }
 
     if ( hdr->version < VERSION(2,8) )
     {
-        if ( verbose )
-            xc_dom_panic(XC_INVALID_KERNEL, "%s: boot protocol too old (%04x)\n",
-                         __FUNCTION__, hdr->version);
+        xc_dom_panic(XC_INVALID_KERNEL, "%s: boot protocol too old (%04x)\n",
+                     __FUNCTION__, hdr->version);
         return -EINVAL;
     }
 
     dom->kernel_blob = dom->kernel_blob + payload_offset(hdr);
     dom->kernel_size = hdr->payload_length;
 
-    if ( xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size) == -1 )
+    if ( memcmp(dom->kernel_blob, "\037\213", 2) == 0 )
+    {
+        ret = xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size);
+        if ( ret == -1 )
+        {
+            xc_dom_panic(XC_INVALID_KERNEL,
+                         "%s: unable to gzip decompress kernel\n",
+                         __FUNCTION__);
+            return -EINVAL;
+        }
+    }
+    else if ( memcmp(dom->kernel_blob, "\102\132\150", 3) == 0 )
     {
-        if ( verbose )
-            xc_dom_panic(XC_INVALID_KERNEL, "%s: unable to decompress kernel\n",
+        ret = xc_try_bzip2_decode(dom, &dom->kernel_blob, &dom->kernel_size);
+        if ( ret < 0 )
+        {
+            xc_dom_panic(XC_INVALID_KERNEL,
+                         "%s unable to BZIP2 decompress kernel",
                          __FUNCTION__);
+            return -EINVAL;
+        }
+    }
+    else if ( memcmp(dom->kernel_blob, "\135\000", 2) == 0 )
+    {
+        ret = xc_try_lzma_decode(dom, &dom->kernel_blob, &dom->kernel_size);
+        if ( ret < 0 )
+        {
+            xc_dom_panic(XC_INVALID_KERNEL,
+                         "%s unable to LZMA decompress kernel\n",
+                         __FUNCTION__);
+            return -EINVAL;
+        }
+    }
+    else
+    {
+        xc_dom_panic(XC_INVALID_KERNEL, "%s: unknown compression format\n",
+                     __FUNCTION__);
         return -EINVAL;
     }
 
     return elf_loader.probe(dom);
 }
 
-static int xc_dom_probe_bzimage_kernel(struct xc_dom_image *dom)
-{
-    return check_bzimage_kernel(dom, 0);
-}
-
 static int xc_dom_parse_bzimage_kernel(struct xc_dom_image *dom)
 {
     return elf_loader.parser(dom);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] pv bootloader support for bzip2/lzma compressed kernels for Xen 3.4.2

[Keir Fraser]

On 15/10/2009 18:38, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:

>> 
>> It's about time to tag an rc for that. I'll look into it next week.
>> 
> 
> Keir: Please include the attached bzip2/lzma pv bootloader patch to Xen
> 3.4-testing for 3.4.2.
> 
> It's a backport from xen-unstable. It's included in Fedora 12/rawhide
> Xen rpms and seems to work OK. No pvgrub (stubdom) support yet.

I backport specific named changesets from xen-unstable. In this case I
assume this will be 20103, 20104 and 20116.

 -- Keir

Re: [PATCH] pv bootloader support for bzip2/lzma compressed kernels for Xen 3.4.2

[Pasi Kärkkäinen]

On Thu, Oct 15, 2009 at 07:11:12PM +0100, Keir Fraser wrote:
> On 15/10/2009 18:38, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> 
> >> 
> >> It's about time to tag an rc for that. I'll look into it next week.
> >> 
> > 
> > Keir: Please include the attached bzip2/lzma pv bootloader patch to Xen
> > 3.4-testing for 3.4.2.
> > 
> > It's a backport from xen-unstable. It's included in Fedora 12/rawhide
> > Xen rpms and seems to work OK. No pvgrub (stubdom) support yet.
> 
> I backport specific named changesets from xen-unstable. In this case I
> assume this will be 20103, 20104 and 20116.
> 

Ok. Yeah, iirc those are the needed changesets.

-- Pasi