[PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[Andrew Cooper]

The legacy save/restore infrastructure requires several function pointers from
the toolstack (libxl or Xend in the past) in order to work, and for HVM guests
also need to be able to play around in dom0's filesystem to move the device
model save record.

Migration v2 changes some of this, but is similarly dependent on
toolstack-provided function pointers.

Someone who wishes to re-architect the interaction of moving parts for running
a domain might be in a position to re-enabled this, but for now, explicitly
fail with ENOSYS (from xc_nomigrate.c) rather than failing with an error about
a missing function pointer (or indeed falling over a NULL pointer on certain
paths).

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxc/Makefile |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index bd2ca6c..735afdb 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -4,6 +4,11 @@ include $(XEN_ROOT)/tools/Rules.mk
 MAJOR    = 4.5
 MINOR    = 0
 
+ifeq ($(CONFIG_LIBXC_MINIOS),y)
+# Save/restore of a domain is currently incompatible with a stubdom environment
+override CONFIG_MIGRATE := n
+endif
+
 CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
-- 
1.7.10.4

Re: [PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[Ian Campbell]

On Tue, 2015-01-27 at 16:58 +0000, Andrew Cooper wrote:
> The legacy save/restore infrastructure requires several function pointers from
> the toolstack (libxl or Xend in the past) in order to work, and for HVM guests
> also need to be able to play around in dom0's filesystem to move the device
> model save record.
> 
> Migration v2 changes some of this, but is similarly dependent on
> toolstack-provided function pointers.
> 
> Someone who wishes to re-architect the interaction of moving parts for running
> a domain might be in a position to re-enabled this, but for now, explicitly
> fail with ENOSYS (from xc_nomigrate.c) rather than failing with an error about
> a missing function pointer (or indeed falling over a NULL pointer on certain
> paths).

You are talking about a toolstack which is itself running in a stubdom
here, right?

As opposed to e.g. an HVM domain using a qemu-stubdom, but being
migrated by a normal toolstack in domain 0 (or at least, not in a
mini-os based stubdom).

Ian.

> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/libxc/Makefile |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index bd2ca6c..735afdb 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -4,6 +4,11 @@ include $(XEN_ROOT)/tools/Rules.mk
>  MAJOR    = 4.5
>  MINOR    = 0
>  
> +ifeq ($(CONFIG_LIBXC_MINIOS),y)
> +# Save/restore of a domain is currently incompatible with a stubdom environment
> +override CONFIG_MIGRATE := n
> +endif
> +
>  CTRL_SRCS-y       :=
>  CTRL_SRCS-y       += xc_core.c
>  CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c

Re: [PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[Andrew Cooper]

On 27/01/15 17:01, Ian Campbell wrote:
> On Tue, 2015-01-27 at 16:58 +0000, Andrew Cooper wrote:
>> The legacy save/restore infrastructure requires several function pointers from
>> the toolstack (libxl or Xend in the past) in order to work, and for HVM guests
>> also need to be able to play around in dom0's filesystem to move the device
>> model save record.
>>
>> Migration v2 changes some of this, but is similarly dependent on
>> toolstack-provided function pointers.
>>
>> Someone who wishes to re-architect the interaction of moving parts for running
>> a domain might be in a position to re-enabled this, but for now, explicitly
>> fail with ENOSYS (from xc_nomigrate.c) rather than failing with an error about
>> a missing function pointer (or indeed falling over a NULL pointer on certain
>> paths).
> You are talking about a toolstack which is itself running in a stubdom
> here, right?

The patch here prevents libxenguest, when compiled as part of a minios
stub environment, from offering migration capability to the sub environment.

One would need to construct a stub environment with libxl and
libxl-save-helper to have a decent stab at making migration of PV guests
from a stub environment work.

>
> As opposed to e.g. an HVM domain using a qemu-stubdom, but being
> migrated by a normal toolstack in domain 0 (or at least, not in a
> mini-os based stubdom).

A qemu-stubdom equally cant participate in migrate of its domain
(because of the issues in passing the qemu save record), but that is a
separate issue.

~Andrew

>
> Ian.
>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> ---
>>  tools/libxc/Makefile |    5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
>> index bd2ca6c..735afdb 100644
>> --- a/tools/libxc/Makefile
>> +++ b/tools/libxc/Makefile
>> @@ -4,6 +4,11 @@ include $(XEN_ROOT)/tools/Rules.mk
>>  MAJOR    = 4.5
>>  MINOR    = 0
>>  
>> +ifeq ($(CONFIG_LIBXC_MINIOS),y)
>> +# Save/restore of a domain is currently incompatible with a stubdom environment
>> +override CONFIG_MIGRATE := n
>> +endif
>> +
>>  CTRL_SRCS-y       :=
>>  CTRL_SRCS-y       += xc_core.c
>>  CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
>

Re: [PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[Ian Campbell]

On Tue, 2015-01-27 at 17:10 +0000, Andrew Cooper wrote:
> > As opposed to e.g. an HVM domain using a qemu-stubdom, but being
> > migrated by a normal toolstack in domain 0 (or at least, not in a
> > mini-os based stubdom).
> 
> A qemu-stubdom equally cant participate in migrate of its domain
> (because of the issues in passing the qemu save record), but that is a
> separate issue.

This works today AFAIK, I'm afraid I think it needs to keep working for
the new migration stuff to land.

Ian.

Re: [PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[Andrew Cooper]

On 27/01/15 17:12, Ian Campbell wrote:
> On Tue, 2015-01-27 at 17:10 +0000, Andrew Cooper wrote:
>>> As opposed to e.g. an HVM domain using a qemu-stubdom, but being
>>> migrated by a normal toolstack in domain 0 (or at least, not in a
>>> mini-os based stubdom).
>> A qemu-stubdom equally cant participate in migrate of its domain
>> (because of the issues in passing the qemu save record), but that is a
>> separate issue.
> This works today AFAIK, I'm afraid I think it needs to keep working for
> the new migration stuff to land.

Nothing along these lines is (should be) impacted by legacy vs
migration-v2.  Migration v2 changes the point at which the existing qemu
save record infrastructure is called, but does not change its functionality.

But as I say, this point is unrelated to the purpose of the patch.

~Andrew

Re: [PATCH] tools/libxc: Disable CONFIG_MIGRATE in stubdom environments

[Ian Campbell]

On Tue, 2015-01-27 at 17:24 +0000, Andrew Cooper wrote:
> On 27/01/15 17:12, Ian Campbell wrote:
> > On Tue, 2015-01-27 at 17:10 +0000, Andrew Cooper wrote:
> >>> As opposed to e.g. an HVM domain using a qemu-stubdom, but being
> >>> migrated by a normal toolstack in domain 0 (or at least, not in a
> >>> mini-os based stubdom).
> >> A qemu-stubdom equally cant participate in migrate of its domain
> >> (because of the issues in passing the qemu save record), but that is a
> >> separate issue.
> > This works today AFAIK, I'm afraid I think it needs to keep working for
> > the new migration stuff to land.
> 
> Nothing along these lines is (should be) impacted by legacy vs
> migration-v2.  Migration v2 changes the point at which the existing qemu
> save record infrastructure is called, but does not change its functionality.
> 
> But as I say, this point is unrelated to the purpose of the patch.

Yes, I wasn't sure why you brought it up given that so I wanted to
clarify.

Ian.