[Qemu-devel] [PATCH 0/3] spapr: fix backward migration from POWER9 to POWER8 hosts

[Qemu-devel] [PATCH 0/3] spapr: fix backward migration from POWER9 to POWER8 hosts

[Greg Kurz]

Hi,

It is expected to be able to migrate a guest started with

     -machine max-cpu-compat=power8

from a POWER9 host to a POWER8 host. It works with recent QEMU versions,
but it is badly broken if the destination runs QEMU 2.7 or older.

This can cause problems in cloud environments that still have systems with
older QEMU versions, eg, hosts running ubuntu LTS 16.04.4 (QEMU 2.5) which
are likely to stay around until admins could transition to some newer OS.

This series was lightly tested, but the patches are simple enough, so I'm
confident they shouldn't break anything :)

Please review as I'd like these to go to QEMU 2.11.2 as well.

--
Greg

---

Greg Kurz (3):
      target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
      spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines
      spapr: don't advertise radix GTSE if max-compat-cpu < power9


 hw/ppc/spapr.c       |   19 +++++++++++++------
 target/ppc/machine.c |    5 +++++
 2 files changed, 18 insertions(+), 6 deletions(-)

[Qemu-devel] [PATCH 1/3] target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack

[Greg Kurz]

The pseries-2.7 and older machine types require CPUPPCState::insns_flags
to be strictly equal between source and destination. This checking is
abusive and breaks migration of KVM guests when the host CPU models
are different, even if they are compatible enough to allow the guest
to run transparently. This buggy behaviour was fixed for pseries-2.8
and we added some hacks to allow backward migration of older machine
types. These hacks assume that the CPU belongs to the POWER8 family,
which was true for most KVM based setup we cared about at the time.
But now POWER9 systems are coming, and backward migration of pre 2.8
guests running in POWER8 architected mode from a POWER9 host to a
POWER8 host is broken:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'cpu'
qemu-system-ppc64: load of migration failed: Invalid argument

This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
fix the issue. This is an acceptable hack because these old machine
types only support CPU models that do set PPC_MEM_TLBIE.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 target/ppc/machine.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/target/ppc/machine.c b/target/ppc/machine.c
index 3d6434a006fa..ba1b9e531f97 100644
--- a/target/ppc/machine.c
+++ b/target/ppc/machine.c
@@ -212,6 +212,11 @@ static int cpu_pre_save(void *opaque)
             ;
         cpu->mig_msr_mask = env->msr_mask & ~metamask;
         cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
+        /* CPU models supported by old machines all have PPC_MEM_TLBIE,
+         * so we set it unconditionally to allow backward migration from
+         * a POWER9 host to a POWER8 host.
+         */
+        cpu->mig_insns_flags |= PPC_MEM_TLBIE;
         cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
         cpu->mig_nb_BATs = env->nb_BATs;
     }

Re: [Qemu-devel] [PATCH 1/3] target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack

[David Gibson]

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

On Thu, May 03, 2018 at 11:16:29PM +0200, Greg Kurz wrote:
> The pseries-2.7 and older machine types require CPUPPCState::insns_flags
> to be strictly equal between source and destination. This checking is
> abusive and breaks migration of KVM guests when the host CPU models
> are different, even if they are compatible enough to allow the guest
> to run transparently. This buggy behaviour was fixed for pseries-2.8
> and we added some hacks to allow backward migration of older machine
> types. These hacks assume that the CPU belongs to the POWER8 family,
> which was true for most KVM based setup we cared about at the time.
> But now POWER9 systems are coming, and backward migration of pre 2.8
> guests running in POWER8 architected mode from a POWER9 host to a
> POWER8 host is broken:
> 
> qemu-system-ppc64: error while loading state for instance 0x0 of device
>  'cpu'
> qemu-system-ppc64: load of migration failed: Invalid argument
> 
> This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
> while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
> fix the issue. This is an acceptable hack because these old machine
> types only support CPU models that do set PPC_MEM_TLBIE.
> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  target/ppc/machine.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/target/ppc/machine.c b/target/ppc/machine.c
> index 3d6434a006fa..ba1b9e531f97 100644
> --- a/target/ppc/machine.c
> +++ b/target/ppc/machine.c
> @@ -212,6 +212,11 @@ static int cpu_pre_save(void *opaque)
>              ;
>          cpu->mig_msr_mask = env->msr_mask & ~metamask;
>          cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
> +        /* CPU models supported by old machines all have PPC_MEM_TLBIE,
> +         * so we set it unconditionally to allow backward migration from
> +         * a POWER9 host to a POWER8 host.

So.. the comment's slightly misleading.  This code is common to all
cpus, not just those used on pseries, so across that set it's not
really accurate.  But pseries is the only machine we support migration
to/from old versions with so it doesn't really matter.

> +         */
> +        cpu->mig_insns_flags |= PPC_MEM_TLBIE;
>          cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
>          cpu->mig_nb_BATs = env->nb_BATs;
>      }
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [PATCH 1/3] target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack

[Greg Kurz]

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

On Fri, 4 May 2018 10:12:23 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, May 03, 2018 at 11:16:29PM +0200, Greg Kurz wrote:
> > The pseries-2.7 and older machine types require CPUPPCState::insns_flags
> > to be strictly equal between source and destination. This checking is
> > abusive and breaks migration of KVM guests when the host CPU models
> > are different, even if they are compatible enough to allow the guest
> > to run transparently. This buggy behaviour was fixed for pseries-2.8
> > and we added some hacks to allow backward migration of older machine
> > types. These hacks assume that the CPU belongs to the POWER8 family,
> > which was true for most KVM based setup we cared about at the time.
> > But now POWER9 systems are coming, and backward migration of pre 2.8
> > guests running in POWER8 architected mode from a POWER9 host to a
> > POWER8 host is broken:
> > 
> > qemu-system-ppc64: error while loading state for instance 0x0 of device
> >  'cpu'
> > qemu-system-ppc64: load of migration failed: Invalid argument
> > 
> > This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
> > while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
> > fix the issue. This is an acceptable hack because these old machine
> > types only support CPU models that do set PPC_MEM_TLBIE.
> > 
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  target/ppc/machine.c |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/target/ppc/machine.c b/target/ppc/machine.c
> > index 3d6434a006fa..ba1b9e531f97 100644
> > --- a/target/ppc/machine.c
> > +++ b/target/ppc/machine.c
> > @@ -212,6 +212,11 @@ static int cpu_pre_save(void *opaque)
> >              ;
> >          cpu->mig_msr_mask = env->msr_mask & ~metamask;
> >          cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
> > +        /* CPU models supported by old machines all have PPC_MEM_TLBIE,
> > +         * so we set it unconditionally to allow backward migration from
> > +         * a POWER9 host to a POWER8 host.  
> 
> So.. the comment's slightly misleading.  This code is common to all
> cpus, not just those used on pseries, so across that set it's not
> really accurate.  But pseries is the only machine we support migration
> to/from old versions with so it doesn't really matter.
> 

Oh... I was assuming that we only supported migration for pseries
machine, irrespective of the versions.

> > +         */
> > +        cpu->mig_insns_flags |= PPC_MEM_TLBIE;
> >          cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
> >          cpu->mig_nb_BATs = env->nb_BATs;
> >      }
> >   
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [PATCH 1/3] target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack

[David Gibson]

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

On Fri, May 04, 2018 at 07:54:19AM +0200, Greg Kurz wrote:
> On Fri, 4 May 2018 10:12:23 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, May 03, 2018 at 11:16:29PM +0200, Greg Kurz wrote:
> > > The pseries-2.7 and older machine types require CPUPPCState::insns_flags
> > > to be strictly equal between source and destination. This checking is
> > > abusive and breaks migration of KVM guests when the host CPU models
> > > are different, even if they are compatible enough to allow the guest
> > > to run transparently. This buggy behaviour was fixed for pseries-2.8
> > > and we added some hacks to allow backward migration of older machine
> > > types. These hacks assume that the CPU belongs to the POWER8 family,
> > > which was true for most KVM based setup we cared about at the time.
> > > But now POWER9 systems are coming, and backward migration of pre 2.8
> > > guests running in POWER8 architected mode from a POWER9 host to a
> > > POWER8 host is broken:
> > > 
> > > qemu-system-ppc64: error while loading state for instance 0x0 of device
> > >  'cpu'
> > > qemu-system-ppc64: load of migration failed: Invalid argument
> > > 
> > > This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
> > > while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
> > > fix the issue. This is an acceptable hack because these old machine
> > > types only support CPU models that do set PPC_MEM_TLBIE.
> > > 
> > > Signed-off-by: Greg Kurz <groug@kaod.org>
> > > ---
> > >  target/ppc/machine.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/target/ppc/machine.c b/target/ppc/machine.c
> > > index 3d6434a006fa..ba1b9e531f97 100644
> > > --- a/target/ppc/machine.c
> > > +++ b/target/ppc/machine.c
> > > @@ -212,6 +212,11 @@ static int cpu_pre_save(void *opaque)
> > >              ;
> > >          cpu->mig_msr_mask = env->msr_mask & ~metamask;
> > >          cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
> > > +        /* CPU models supported by old machines all have PPC_MEM_TLBIE,
> > > +         * so we set it unconditionally to allow backward migration from
> > > +         * a POWER9 host to a POWER8 host.  
> > 
> > So.. the comment's slightly misleading.  This code is common to all
> > cpus, not just those used on pseries, so across that set it's not
> > really accurate.  But pseries is the only machine we support migration
> > to/from old versions with so it doesn't really matter.
> 
> Oh... I was assuming that we only supported migration for pseries
> machine, irrespective of the versions.

Actually, that's probably true.  Although there are a couple where it
might just about work.  pseries is *definitely* the only one that we
properly check and care about cross-version compatibility though.


> 
> > > +         */
> > > +        cpu->mig_insns_flags |= PPC_MEM_TLBIE;
> > >          cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
> > >          cpu->mig_nb_BATs = env->nb_BATs;
> > >      }
> > >   
> > 
> 



-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[Qemu-devel] [PATCH 2/3] spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines

[Greg Kurz]

a324d6f16697 "spapr: Support ibm,dynamic-memory-v2 property" added
a new feature in the set of CAS-negotiatable options. This causes
the CAS-negotiated options subsection to be migrated, even for old
machine types that don't know about it, and breaks backward migration
to QEMU 2.7 and older versions:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory

Since this feature only affects boot time behaviour, it should be
filtered out when we decide to migrate CAS-negotiated options, like
we already do with OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/ppc/spapr.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index b35aff5d811c..eb9d087d1a60 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1851,10 +1851,12 @@ static bool spapr_ov5_cas_needed(void *opaque)
      *
      * Thus, for any cases where the set of available CAS-negotiatable
      * options extends beyond OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY, we
-     * include the CAS-negotiated options in the migration stream.
+     * include the CAS-negotiated options in the migration stream, unless
+     * if they affect boot time behaviour only.
      */
     spapr_ovec_set(ov5_mask, OV5_FORM1_AFFINITY);
     spapr_ovec_set(ov5_mask, OV5_DRCONF_MEMORY);
+    spapr_ovec_set(ov5_mask, OV5_DRMEM_V2);
 
     /* spapr_ovec_diff returns true if bits were removed. we avoid using
      * the mask itself since in the future it's possible "legacy" bits may be

[Qemu-devel] [PATCH 3/3] spapr: don't advertise radix GTSE if max-compat-cpu < power9

[Greg Kurz]

On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily
uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in
the ibm,arch-vec-5-platform-support DT property as the current code does.
The first reason is that it doesn't make sense, and the second one is that
causes the CAS-negotiated options subsection to be migrated. This breaks
backward migration to QEMU 2.7 and older versions on POWER8 hosts:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory

This patch hence initialize CPUs a bit earlier so that we can check the
requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and
older.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/ppc/spapr.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index eb9d087d1a60..154bf9d548c4 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2517,6 +2517,7 @@ static void spapr_machine_init(MachineState *machine)
     long load_limit, fw_size;
     char *filename;
     Error *resize_hpt_err = NULL;
+    PowerPCCPU *first_ppc_cpu;
 
     msi_nonbroken = true;
 
@@ -2609,11 +2610,6 @@ static void spapr_machine_init(MachineState *machine)
     }
 
     spapr_ovec_set(spapr->ov5, OV5_FORM1_AFFINITY);
-    if (!kvm_enabled() || kvmppc_has_cap_mmu_radix()) {
-        /* KVM and TCG always allow GTSE with radix... */
-        spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
-    }
-    /* ... but not with hash (currently). */
 
     /* advertise support for dedicated HP event source to guests */
     if (spapr->use_hotplug_event_source) {
@@ -2631,6 +2627,15 @@ static void spapr_machine_init(MachineState *machine)
     /* init CPUs */
     spapr_init_cpus(spapr);
 
+    first_ppc_cpu = POWERPC_CPU(first_cpu);
+    if ((!kvm_enabled() || kvmppc_has_cap_mmu_radix()) &&
+        ppc_check_compat(first_ppc_cpu, CPU_POWERPC_LOGICAL_3_00, 0,
+                         spapr->max_compat_pvr)) {
+        /* KVM and TCG always allow GTSE with radix... */
+        spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
+    }
+    /* ... but not with hash (currently). */
+
     if (kvm_enabled()) {
         /* Enable H_LOGICAL_CI_* so SLOF can talk to in-kernel devices */
         kvmppc_enable_logical_ci_hcalls();

Re: [Qemu-devel] [PATCH 0/3] spapr: fix backward migration from POWER9 to POWER8 hosts

[David Gibson]

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

On Thu, May 03, 2018 at 11:16:10PM +0200, Greg Kurz wrote:
> Hi,
> 
> It is expected to be able to migrate a guest started with
> 
>      -machine max-cpu-compat=power8
> 
> from a POWER9 host to a POWER8 host. It works with recent QEMU versions,
> but it is badly broken if the destination runs QEMU 2.7 or older.
> 
> This can cause problems in cloud environments that still have systems with
> older QEMU versions, eg, hosts running ubuntu LTS 16.04.4 (QEMU 2.5) which
> are likely to stay around until admins could transition to some newer OS.
> 
> This series was lightly tested, but the patches are simple enough, so I'm
> confident they shouldn't break anything :)
> 
> Please review as I'd like these to go to QEMU 2.11.2 as well.

Applied to ppc-for-2.13.  As you say, these should probably go to the
2.12 and 2.11 stable trees too.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [PATCH 0/3] spapr: fix backward migration from POWER9 to POWER8 hosts

[Greg Kurz]

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

On Fri, 4 May 2018 10:11:02 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, May 03, 2018 at 11:16:10PM +0200, Greg Kurz wrote:
> > Hi,
> > 
> > It is expected to be able to migrate a guest started with
> > 
> >      -machine max-cpu-compat=power8
> > 
> > from a POWER9 host to a POWER8 host. It works with recent QEMU versions,
> > but it is badly broken if the destination runs QEMU 2.7 or older.
> > 
> > This can cause problems in cloud environments that still have systems with
> > older QEMU versions, eg, hosts running ubuntu LTS 16.04.4 (QEMU 2.5) which
> > are likely to stay around until admins could transition to some newer OS.
> > 
> > This series was lightly tested, but the patches are simple enough, so I'm
> > confident they shouldn't break anything :)
> > 
> > Please review as I'd like these to go to QEMU 2.11.2 as well.  
> 
> Applied to ppc-for-2.13.  As you say, these should probably go to the
> 2.12 and 2.11 stable trees too.
> 

Cc'ing qemu-stable then

Cheers,

--
Greg

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [PATCH 0/3] spapr: fix backward migration from POWER9 to POWER8 hosts

[David Gibson]

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

On Fri, May 04, 2018 at 07:58:21AM +0200, Greg Kurz wrote:
> On Fri, 4 May 2018 10:11:02 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, May 03, 2018 at 11:16:10PM +0200, Greg Kurz wrote:
> > > Hi,
> > > 
> > > It is expected to be able to migrate a guest started with
> > > 
> > >      -machine max-cpu-compat=power8
> > > 
> > > from a POWER9 host to a POWER8 host. It works with recent QEMU versions,
> > > but it is badly broken if the destination runs QEMU 2.7 or older.
> > > 
> > > This can cause problems in cloud environments that still have systems with
> > > older QEMU versions, eg, hosts running ubuntu LTS 16.04.4 (QEMU 2.5) which
> > > are likely to stay around until admins could transition to some newer OS.
> > > 
> > > This series was lightly tested, but the patches are simple enough, so I'm
> > > confident they shouldn't break anything :)
> > > 
> > > Please review as I'd like these to go to QEMU 2.11.2 as well.  
> > 
> > Applied to ppc-for-2.13.  As you say, these should probably go to the
> > 2.12 and 2.11 stable trees too.
> > 
> 
> Cc'ing qemu-stable then

Thanks.  I'm about to go on leave, so I won't be around to shepherd
these into the stable trees any time soon.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [PATCH 0/3] spapr: fix backward migration from POWER9 to POWER8 hosts

[Greg Kurz]

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

On Fri, 4 May 2018 16:37:19 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Fri, May 04, 2018 at 07:58:21AM +0200, Greg Kurz wrote:
> > On Fri, 4 May 2018 10:11:02 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Thu, May 03, 2018 at 11:16:10PM +0200, Greg Kurz wrote:  
> > > > Hi,
> > > > 
> > > > It is expected to be able to migrate a guest started with
> > > > 
> > > >      -machine max-cpu-compat=power8
> > > > 
> > > > from a POWER9 host to a POWER8 host. It works with recent QEMU versions,
> > > > but it is badly broken if the destination runs QEMU 2.7 or older.
> > > > 
> > > > This can cause problems in cloud environments that still have systems with
> > > > older QEMU versions, eg, hosts running ubuntu LTS 16.04.4 (QEMU 2.5) which
> > > > are likely to stay around until admins could transition to some newer OS.
> > > > 
> > > > This series was lightly tested, but the patches are simple enough, so I'm
> > > > confident they shouldn't break anything :)
> > > > 
> > > > Please review as I'd like these to go to QEMU 2.11.2 as well.    
> > > 
> > > Applied to ppc-for-2.13.  As you say, these should probably go to the
> > > 2.12 and 2.11 stable trees too.
> > >   
> > 
> > Cc'ing qemu-stable then  
> 
> Thanks.  I'm about to go on leave, so I won't be around to shepherd
> these into the stable trees any time soon.
> 

No problem. I'll take care of that with Mike.

Have a good *disconnected as much as possible* holiday ! :)

Cheers,

--
Greg

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]