[ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Ian Campbell]

The time has come for another round of stable releases.

Please send (or resend) any outstanding backport requests for 4.0.4 and
4.1.3 before Friday 20 April.

Note that 4.0.4 will likely be the last release in the 4.0.x branch.

Ian.

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Jan Beulich]

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

>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

4.1:
24996:396801f25e92

4.1 and 4.0:
25098:2e45b26bc412 + 25099:4bd752a4cdf3
25101:f06ff3dfde08

4.1 backports attached (apply with some offsets, since they're taken
directly form our SLE11 SP2 tree).

Jan


[-- Attachment #2: 24996-x86-cpuidle-array-overrun.patch --]
[-- Type: text/plain, Size: 5137 bytes --]

# HG changeset patch
# User Eric Chanudet <eric.chanudet@eu.citrix.com>
# Date 1331222672 -3600
# Node ID 396801f25e922bdf1db5fd644435f46407586524
# Parent  66de4220113e937811529b12ea7f6427c0848630
XENPF_set_processor_pminfo XEN_PM_CX overflows states array

Calling XENPF_set_processor_pminfo with XEN_PM_CX could cause states
array in "struct acpi_processor_power" to exceed its limit.

The array used to be reset (by function cpuidle_init_cpu()) for each
hypercall. The patch puts it back that way and adds an assertion to
make it clear in case that happens again.

Signed-off-by: Eric Chanudet <eric.chanudet@eu.citrix.com>

- convert assertion to printk() & bail
- eliminate struct acpi_processor_cx's valid member (not read anymore)
- further adjustments to one-time-only vs each-time operations in
  cpuidle_init_cpu()
- don't use ACPI_STATE_Cn as array index anymore

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -70,10 +70,8 @@ static void lapic_timer_nop(void) { }
 static void (*lapic_timer_off)(void);
 static void (*lapic_timer_on)(void);
 
-static uint64_t (*get_tick)(void);
-static uint64_t (*ticks_elapsed)(uint64_t t1, uint64_t t2);
-static uint64_t (*tick_to_ns)(uint64_t ticks);
-static uint64_t (*ns_to_tick)(uint64_t ticks);
+static uint64_t (*__read_mostly tick_to_ns)(uint64_t) = acpi_pm_tick_to_ns;
+static uint64_t (*__read_mostly ns_to_tick)(uint64_t) = ns_to_acpi_pm_tick;
 
 extern void (*pm_idle) (void);
 extern void (*dead_idle) (void);
@@ -224,6 +222,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui
         return ((0xFFFFFFFF - t1) + t2 +1);
 }
 
+static uint64_t (*__read_mostly get_tick)(void) = get_acpi_pm_tick;
+static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)
+    = acpi_pm_ticks_elapsed;
+
 #define MWAIT_ECX_INTERRUPT_BREAK   (0x1)
 
 /*
@@ -609,7 +611,16 @@ static int cpuidle_init_cpu(int cpu)
     acpi_power = processor_powers[cpu];
     if ( !acpi_power )
     {
-        int i;
+        unsigned int i;
+
+        if ( cpu == 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+        {
+            get_tick = get_stime_tick;
+            ticks_elapsed = stime_ticks_elapsed;
+            tick_to_ns = stime_tick_to_ns;
+            ns_to_tick = ns_to_stime_tick;
+        }
+
         acpi_power = xmalloc(struct acpi_processor_power);
         if ( !acpi_power )
             return -ENOMEM;
@@ -617,36 +628,15 @@ static int cpuidle_init_cpu(int cpu)
 
         for ( i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++ )
             acpi_power->states[i].idx = i;
-     
-        acpi_power->states[ACPI_STATE_C1].type = ACPI_STATE_C1;
-        acpi_power->states[ACPI_STATE_C1].entry_method = ACPI_CSTATE_EM_HALT;
-     
-        acpi_power->states[ACPI_STATE_C0].valid = 1;
-        acpi_power->states[ACPI_STATE_C1].valid = 1;
-     
-        acpi_power->count = 2;
-        acpi_power->safe_state = &acpi_power->states[ACPI_STATE_C1];
+
         acpi_power->cpu = cpu;
         processor_powers[cpu] = acpi_power;
     }
 
-    if ( cpu == 0 )
-    {
-        if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
-        {
-            get_tick = get_stime_tick;
-            ticks_elapsed = stime_ticks_elapsed;
-            tick_to_ns = stime_tick_to_ns;
-            ns_to_tick = ns_to_stime_tick;
-        }
-        else
-        {
-            get_tick = get_acpi_pm_tick;
-            ticks_elapsed = acpi_pm_ticks_elapsed;
-            tick_to_ns = acpi_pm_tick_to_ns;
-            ns_to_tick = ns_to_acpi_pm_tick;
-        }
-    }
+    acpi_power->count = 2;
+    acpi_power->states[1].type = ACPI_STATE_C1;
+    acpi_power->states[1].entry_method = ACPI_CSTATE_EM_HALT;
+    acpi_power->safe_state = &acpi_power->states[1];
 
     return 0;
 }
@@ -863,17 +853,25 @@ static void set_cx(
     if ( check_cx(acpi_power, xen_cx) != 0 )
         return;
 
-    if ( xen_cx->type == ACPI_STATE_C1 )
+    switch ( xen_cx->type )
+    {
+    case ACPI_STATE_C1:
         cx = &acpi_power->states[1];
-    else
-        cx = &acpi_power->states[acpi_power->count];
-
-    if ( !cx->valid )
-        acpi_power->count++;
+        break;
+    default:
+        if ( acpi_power->count >= ACPI_PROCESSOR_MAX_POWER )
+        {
+    case ACPI_STATE_C0:
+            printk(XENLOG_WARNING "CPU%u: C%d data ignored\n",
+                   acpi_power->cpu, xen_cx->type);
+            return;
+        }
+        cx = &acpi_power->states[acpi_power->count++];
+        cx->type = xen_cx->type;
+        break;
+    }
 
-    cx->valid    = 1;
-    cx->type     = xen_cx->type;
-    cx->address  = xen_cx->reg.address;
+    cx->address = xen_cx->reg.address;
 
     switch ( xen_cx->reg.space_id )
     {
--- a/xen/include/xen/cpuidle.h
+++ b/xen/include/xen/cpuidle.h
@@ -40,7 +40,6 @@
 struct acpi_processor_cx
 {
     u8 idx;
-    u8 valid;
     u8 type;
     u32 address;
     u8 entry_method; /* ACPI_CSTATE_EM_xxx */

[-- Attachment #3: 25098-x86-emul-lock-UD.patch --]
[-- Type: text/plain, Size: 2779 bytes --]

# HG changeset patch
# User Andrew Cooper <andrew.cooper3@citrix.com>
# Date 1332535516 0
# Node ID 2e45b26bc412099a2b8f009bcf111e4b6c23847b
# Parent  2ca43b65718fbe2d3f9ea36132e139ef774d9a11
x86_emulate: raise #UD rather than #GP on invalid use of LOCK prefix

From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>

# HG changeset patch
# User Keir Fraser <keir@xen.org>
# Date 1332535908 0
# Node ID 4bd752a4cdf323c41c50f8cd6286f566d67adeae
# Parent  2e45b26bc412099a2b8f009bcf111e4b6c23847b
x86_emulate: Do not push an error code onto a #UD exception stack

Signed-off-by: Keir Fraser <keir@xen.org>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1353,7 +1353,7 @@ x86_emulate(
     }
 
     /* Lock prefix is allowed only on RMW instructions. */
-    generate_exception_if((d & Mov) && lock_prefix, EXC_GP, 0);
+    generate_exception_if((d & Mov) && lock_prefix, EXC_UD, -1);
 
     /* ModRM and SIB bytes. */
     if ( d & ModRM )
@@ -1572,12 +1572,12 @@ x86_emulate(
             lock_prefix &&
             ((b < 0x20) || (b > 0x23)) && /* MOV CRn/DRn */
             (b != 0xc7),                  /* CMPXCHG{8,16}B */
-            EXC_GP, 0);
+            EXC_UD, -1);
         dst.type = OP_NONE;
         break;
 
     case DstReg:
-        generate_exception_if(lock_prefix, EXC_GP, 0);
+        generate_exception_if(lock_prefix, EXC_UD, -1);
         dst.type = OP_REG;
         if ( d & ByteOp )
         {
@@ -1633,7 +1633,7 @@ x86_emulate(
         dst = ea;
         if ( dst.type == OP_REG )
         {
-            generate_exception_if(lock_prefix, EXC_GP, 0);
+            generate_exception_if(lock_prefix, EXC_UD, -1);
             switch ( dst.bytes )
             {
             case 1: dst.val = *(uint8_t  *)dst.reg; break;
@@ -3645,14 +3645,14 @@ x86_emulate(
         struct segment_register cs = { 0 }, ss = { 0 };
         int rc;
 
-        generate_exception_if(in_realmode(ctxt, ops), EXC_UD, 0);
-        generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, 0);
+        generate_exception_if(in_realmode(ctxt, ops), EXC_UD, -1);
+        generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 
         /* Inject #UD if syscall/sysret are disabled. */
         fail_if(ops->read_msr == NULL);
         if ( (rc = ops->read_msr(MSR_EFER, &msr_content, ctxt)) != 0 )
             goto done;
-        generate_exception_if((msr_content & EFER_SCE) == 0, EXC_UD, 0);
+        generate_exception_if((msr_content & EFER_SCE) == 0, EXC_UD, -1);
 
         if ( (rc = ops->read_msr(MSR_STAR, &msr_content, ctxt)) != 0 )
             goto done;

[-- Attachment #4: 25101-x86-hpet-disable.patch --]
[-- Type: text/plain, Size: 3573 bytes --]

References: bnc#748896

# HG changeset patch
# User Jan Beulich <jbeulich@suse.com>
# Date 1332854423 -7200
# Node ID f06ff3dfde08ee563970cffba502742249ff5820
# Parent  ed48258053aea953afd28b746b53af7b8b30531b
x86/hpet: disable before reboot or kexec

Linux up to now is not smart enough to properly clear the HPET when it
boots, which is particularly a problem when a kdump attempt from
running under Xen is being made. Linux itself added code to work around
this to its shutdown paths quite some time ago, so let's do something
similar in Xen: Save the configuration register settings during boot,
and restore them during shutdown. This should cover the majority of
cases where the secondary kernel might not come up because timer
interrupts don't work.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>

--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -94,6 +94,7 @@ static void nmi_shootdown_cpus(void)
     x2apic_enabled = (current_local_apic_mode() == APIC_MODE_X2APIC);
 
     disable_IO_APIC();
+    hpet_disable();
 }
 
 void machine_crash_shutdown(void)
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -721,12 +721,14 @@ int hpet_legacy_irq_tick(void)
     return 1;
 }
 
+static u32 *hpet_boot_cfg;
+
 u64 hpet_setup(void)
 {
     static u64 hpet_rate;
     static u32 system_reset_latch;
     u32 hpet_id, hpet_period, cfg;
-    int i;
+    unsigned int i, last;
 
     if ( system_reset_latch == system_reset_counter )
         return hpet_rate;
@@ -752,13 +754,20 @@ u64 hpet_setup(void)
         return 0;
     }
 
+    last = (hpet_id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT;
+    hpet_boot_cfg = xmalloc_array(u32, 2 + last);
+
     cfg = hpet_read32(HPET_CFG);
+    if ( hpet_boot_cfg )
+        *hpet_boot_cfg = cfg;
     cfg &= ~(HPET_CFG_ENABLE | HPET_CFG_LEGACY);
     hpet_write32(cfg, HPET_CFG);
 
-    for ( i = 0; i <= ((hpet_id >> 8) & 31); i++ )
+    for ( i = 0; i <= last; ++i )
     {
         cfg = hpet_read32(HPET_Tn_CFG(i));
+        if ( hpet_boot_cfg )
+            hpet_boot_cfg[i + 1] = cfg;
         cfg &= ~HPET_TN_ENABLE;
         hpet_write32(cfg, HPET_Tn_CFG(i));
     }
@@ -772,3 +781,21 @@ u64 hpet_setup(void)
 
     return hpet_rate;
 }
+
+void hpet_disable(void)
+{
+    unsigned int i;
+    u32 id;
+
+    if ( !hpet_boot_cfg )
+        return;
+
+    hpet_write32(*hpet_boot_cfg & ~HPET_CFG_ENABLE, HPET_CFG);
+
+    id = hpet_read32(HPET_ID);
+    for ( i = 0; i <= ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT); ++i )
+        hpet_write32(hpet_boot_cfg[i + 1], HPET_Tn_CFG(i));
+
+    if ( *hpet_boot_cfg & HPET_CFG_ENABLE )
+        hpet_write32(*hpet_boot_cfg, HPET_CFG);
+}
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -19,6 +19,7 @@
 #include <asm/mc146818rtc.h>
 #include <asm/flushtlb.h>
 #include <asm/hardirq.h>
+#include <asm/hpet.h>
 #include <asm/hvm/support.h>
 #include <mach_apic.h>
 
@@ -373,6 +374,7 @@ void smp_send_stop(void)
     local_irq_disable();
     __stop_this_cpu();
     disable_IO_APIC();
+    hpet_disable();
     local_irq_enable();
 }
 
--- a/xen/include/asm-x86/hpet.h
+++ b/xen/include/asm-x86/hpet.h
@@ -68,6 +68,11 @@ extern unsigned long hpet_address;
 u64 hpet_setup(void);
 
 /*
+ * Disable HPET hardware: restore it to boot time state.
+ */
+void hpet_disable(void);
+
+/*
  * Callback from legacy timer (PIT channel 0) IRQ handler.
  * Returns 1 if tick originated from HPET; else 0.
  */

[-- Attachment #5: Type: text/plain, Size: 126 bytes --]

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

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Stefano Stabellini]

On Thu, 12 Apr 2012, Ian Campbell wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
> 
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.

For 4.1.x:

289eb8848224efb649dc42a9bb3c086553cc2922 qemu-xen-traditional: QDISK fixes
f8d95ca183c7d6072c2871588bde1fef7c601e22 qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
bbe85879171f78463f777c1e47273de24d8a64ce qemu-xen-traditional: use O_DIRECT to open disk images for IDE

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Teck Choon Giam]

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

On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

I don't know whether can non-commit xen-unstable be considered for
backport so I am trying since deadline is before coming Friday 20
April 2012.

libxl/xend: name tap devices with a xentap prefix

Reference: http://lists.xen.org/archives/html/xen-devel/2012-04/msg01223.html

My backport has a modification as stated in
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01374.html
about the line:

vifname = "xen-" + vifname

to:

vifname = "xentap-" + vifname

The backport patch is attached and tested with xen-4.1-testing
changeset 23283:494aa5ecd2e1 using xm and xl.

Thanks.

Kindest regards,
Giam Teck Choon

[-- Attachment #2: rename-net-tap-to-xentap.patch --]
[-- Type: application/octet-stream, Size: 4479 bytes --]

libxl/xend: name tap devices with a xentap prefix

This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)

Also add "xentap-" prefix to the tap device when an explicit name is given to
avoid a conflict with the vif device, which would otherwise have the same name.
Likewise correct the documentation for this option which suggested it applied
to HVM tap devices only.

Reported by Michael Young.

Backport from http://lists.xen.org/archives/html/xen-devel/2012-04/msg01223.html

Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
---
 tools/hotplug/Linux/vif-common.sh     |    4 ++--
 tools/hotplug/Linux/xen-backend.rules |    2 +-
 tools/libxl/libxl_dm.c                |    8 ++++----
 tools/python/xen/xend/image.py        |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/hotplug/Linux/vif-common.sh b/tools/hotplug/Linux/vif-common.sh
index c9c5d41..23be238 100644
--- a/tools/hotplug/Linux/vif-common.sh
+++ b/tools/hotplug/Linux/vif-common.sh
@@ -85,8 +85,8 @@ elif [ "$type_if" = tap ]; then
     : ${INTERFACE:?}
 
     # Get xenbus_path from device name.
-    # The name is built like that: "tap${domid}.${devid}".
-    dev_=${dev#tap}
+    # The name is built like that: "xentap${domid}.${devid}".
+    dev_=${dev#xentap}
     domid=${dev_%.*}
     devid=${dev_#*.}
 
diff --git a/tools/hotplug/Linux/xen-backend.rules b/tools/hotplug/Linux/xen-backend.rules
index 40f2658..19bd0fa 100644
--- a/tools/hotplug/Linux/xen-backend.rules
+++ b/tools/hotplug/Linux/xen-backend.rules
@@ -13,4 +13,4 @@ KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
 KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
 KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
 KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
-SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
+SUBSYSTEM=="net", KERNEL=="xentap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1ffcc90..1170775 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -136,9 +136,9 @@ static char ** libxl_build_device_model_args_old(libxl__gc *gc,
                                            vifs[i].mac[3], vifs[i].mac[4], vifs[i].mac[5]);
                 char *ifname;
                 if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc, "xentap%d.%d", info->domid, vifs[i].devid);
                 else
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 flexarray_vappend(dm_args,
                                 "-net", libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
                                                        vifs[i].devid, smac, vifs[i].model),
@@ -273,9 +273,9 @@ static char ** libxl_build_device_model_args_new(libxl__gc *gc,
                                            vifs[i].mac[3], vifs[i].mac[4], vifs[i].mac[5]);
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc, "xentap%d.%d", info->domid, vifs[i].devid);
                 } else {
-                    ifname = vifs[i].ifname;
+                    ifname = libxl__sprintf(gc, "xentap-%s", vifs[i].ifname);
                 }
                 flexarray_append(dm_args, "-net");
                 flexarray_append(dm_args, libxl__sprintf(gc, "nic,vlan=%d,macaddr=%s,model=%s",
diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py
index f1464ac..a07bf69 100644
--- a/tools/python/xen/xend/image.py
+++ b/tools/python/xen/xend/image.py
@@ -919,9 +919,9 @@ class HVMImageHandler(ImageHandler):
                        (nics, mac, model))
             vifname = devinfo.get('vifname')
             if vifname:
-                vifname = "tap-" + vifname
+                vifname = "xentap-" + vifname
             else:
-                vifname = "tap%d.%d" % (self.vm.getDomid(), nics-1)
+                vifname = "xentap%d.%d" % (self.vm.getDomid(), nics-1)
             ret.append("-net")
             ret.append("tap,vlan=%d,ifname=%s,bridge=%s" %
                        (nics, vifname, bridge))

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

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

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Jan Beulich]

>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The time has come for another round of stable releases.
> 
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.

As there were no -rc1's so far anyway, I'd like to additionally propose
the first hunk of 25168:d5f9005dfc4a for 4.1.

Further candidates, though more involved in terms of what
they change, appear to be 25191:a95fc7decc83,
25195:a06e6cdeafe3, and 25196:375fa55c7a6c.

Jan

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Keir Fraser]

On 24/04/2012 10:19, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 12.04.12 at 18:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> The time has come for another round of stable releases.
>> 
>> Please send (or resend) any outstanding backport requests for 4.0.4 and
>> 4.1.3 before Friday 20 April.
> 
> As there were no -rc1's so far anyway, I'd like to additionally propose
> the first hunk of 25168:d5f9005dfc4a for 4.1.

I've now done this.

> Further candidates, though more involved in terms of what
> they change, appear to be 25191:a95fc7decc83,
> 25195:a06e6cdeafe3, and 25196:375fa55c7a6c.

Maybe. They're quite big though.

 -- Keir

> Jan
> 

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Ian Jackson]

Stefano Stabellini writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
> On Thu, 12 Apr 2012, Ian Campbell wrote:
> > The time has come for another round of stable releases.
> > 
> > Please send (or resend) any outstanding backport requests for 4.0.4 and
> > 4.1.3 before Friday 20 April.
> > 
> > Note that 4.0.4 will likely be the last release in the 4.0.x branch.
> 
> For 4.1.x:
> 
> 289eb8848224efb649dc42a9bb3c086553cc2922 qemu-xen-traditional: QDISK fixes
> f8d95ca183c7d6072c2871588bde1fef7c601e22 qemu-xen-traditional: use O_DIRECT to open disk images with QDISK
> bbe85879171f78463f777c1e47273de24d8a64ce qemu-xen-traditional: use O_DIRECT to open disk images for IDE

These are not yet in -unstable.  I will backport them when they are
provided we get a test push with them...

Ian.

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Ian Jackson]

Teck Choon Giam writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
> On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > The time has come for another round of stable releases.
> >
> > Please send (or resend) any outstanding backport requests for 4.0.4 and
> > 4.1.3 before Friday 20 April.
> 
> I don't know whether can non-commit xen-unstable be considered for
> backport so I am trying since deadline is before coming Friday 20
> April 2012.
> 
> libxl/xend: name tap devices with a xentap prefix

Yes, I think this is OK in principle but we should wait for the
patches to actually go into -unstable and be tested there, before we
apply them to earlier trees.

IIRC we are waiting for a repost of the -unstable version ?

Ian.

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Teck Choon Giam]

On Wed, Apr 25, 2012 at 12:43 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Teck Choon Giam writes ("Re: [Xen-devel] [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases"):
>> On Fri, Apr 13, 2012 at 12:30 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > The time has come for another round of stable releases.
>> >
>> > Please send (or resend) any outstanding backport requests for 4.0.4 and
>> > 4.1.3 before Friday 20 April.
>>
>> I don't know whether can non-commit xen-unstable be considered for
>> backport so I am trying since deadline is before coming Friday 20
>> April 2012.
>>
>> libxl/xend: name tap devices with a xentap prefix
>
> Yes, I think this is OK in principle but we should wait for the
> patches to actually go into -unstable and be tested there, before we
> apply them to earlier trees.
>
> IIRC we are waiting for a repost of the -unstable version ?

Yes, waiting for the reposts from Ian C. while he is waiting for the
hotplug series (I think) from err... someone (sorry, can't remember
names but I guess is Roger) else to be committed in xen-unstable or
something.  Thanks for letting me know about this is OK to backport
and I agree that we shall wait for it to be committed in xen-unstable
before backporting to earlier tree.
>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Malcolm Crossley]

On 12/04/12 17:30, Ian Campbell wrote:
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
>
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>
> Ian.
Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be 
backported to 4.0 and 4.1?

Thanks,

Malcolm

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[AP]

[-- Attachment #1.1: Type: text/plain, Size: 480 bytes --]

On Apr 12, 2012 9:32 AM, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
> The time has come for another round of stable releases.
>
> Please send (or resend) any outstanding backport requests for 4.0.4 and
> 4.1.3 before Friday 20 April.
>
> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>

I know this comes late in the day but if possible please consider
25218:cf2de273869f, 25255:fd04ba0aa4fa and 25256:9dda0efd8ce1 for backport
to 4.1.3.

Thanks,
AP

[-- Attachment #1.2: Type: text/html, Size: 630 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Keir Fraser]

On 26/04/2012 15:53, "Malcolm Crossley" <malcolm.crossley@citrix.com> wrote:

> On 12/04/12 17:30, Ian Campbell wrote:
>> The time has come for another round of stable releases.
>> 
>> Please send (or resend) any outstanding backport requests for 4.0.4 and
>> 4.1.3 before Friday 20 April.
>> 
>> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>> 
>> Ian.
> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be
> backported to 4.0 and 4.1?

Done.

 -- Keir

> Thanks,
> 
> Malcolm
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Jan Beulich]

>>> On 01.05.12 at 15:19, Keir Fraser <keir@xen.org> wrote:
> On 26/04/2012 15:53, "Malcolm Crossley" <malcolm.crossley@citrix.com> wrote:
> 
>> On 12/04/12 17:30, Ian Campbell wrote:
>>> The time has come for another round of stable releases.
>>> 
>>> Please send (or resend) any outstanding backport requests for 4.0.4 and
>>> 4.1.3 before Friday 20 April.
>>> 
>>> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>>> 
>>> Ian.
>> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be
>> backported to 4.0 and 4.1?
> 
> Done.

Any plan then to tag RC1-s on both trees?

Jan

Re: [ANNOUNCE] backports for 4.0.4 and 4.1.3 stable releases

[Keir Fraser]

On 02/05/2012 09:55, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 01.05.12 at 15:19, Keir Fraser <keir@xen.org> wrote:
>> On 26/04/2012 15:53, "Malcolm Crossley" <malcolm.crossley@citrix.com> wrote:
>> 
>>> On 12/04/12 17:30, Ian Campbell wrote:
>>>> The time has come for another round of stable releases.
>>>> 
>>>> Please send (or resend) any outstanding backport requests for 4.0.4 and
>>>> 4.1.3 before Friday 20 April.
>>>> 
>>>> Note that 4.0.4 will likely be the last release in the 4.0.x branch.
>>>> 
>>>> Ian.
>>> Can 25242:b7ce6a88bebb, 24990:322300fd2ebd and 25058:f47d91cb0faa be
>>> backported to 4.0 and 4.1?
>> 
>> Done.
> 
> Any plan then to tag RC1-s on both trees?

Yes, we could do that this week I think.

 -- Keir

> Jan
>