On Wed, 2014-06-25 at 13:10 -0600, Eric Blake wrote:
On 06/25/2014 12:13 PM, Jim Fehlig wrote:
libxl does not support save, restore, or migrate on all architectures, notably ARM. Detect whether libxl supports these operations using LIBXL_HAVE_NO_SUSPEND_RESUME. If not supported, drop advertisement of <migration_features>.
Found by Ian Campbell while improving Xen's OSSTEST infrastructure
http://lists.xen.org/archives/html/xen-devel/2014-06/msg02171.html Signed-off-by: Jim Fehlig <jfehlig@suse.com> ---
Derived from a test patch I sent to Ian Campbell
http://lists.xen.org/archives/html/xen-devel/2014-06/msg03150.html
Includes fixups Ian provided later in the thread.
I think it looks identical to that combination, in which case you can add my Tested-by: Ian Campbell <ian.campbell@citrix.com> if you want.
src/libxl/libxl_conf.c | 4 ++++ src/libxl/libxl_driver.c | 8 ++++++++ 2 files changed, 12 insertions(+)
+#ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
Double negative logic is hard to read. Oh well.
libxl didn't initially supply a #define (because it only supported x86 which always did migration) and when ARM came along we could only add something to new versions since obviously we can't change already released stuff, so it had to be this way, sadly.
static virDriver libxlDriver = { @@ -4594,10 +4598,12 @@ static virDriver libxlDriver = { .domainSetMemoryFlags = libxlDomainSetMemoryFlags, /* 0.9.0 */ .domainGetInfo = libxlDomainGetInfo, /* 0.9.0 */ .domainGetState = libxlDomainGetState, /* 0.9.2 */ +#ifndef LIBXL_HAVE_NO_SUSPEND_RESUME .domainSave = libxlDomainSave, /* 0.9.2 */ .domainSaveFlags = libxlDomainSaveFlags, /* 0.9.4 */ .domainRestore = libxlDomainRestore, /* 0.9.2 */ .domainRestoreFlags = libxlDomainRestoreFlags, /* 0.9.4 */ +#endif
Hmm - do we do conditional registration in any other driver based on configure-time results? I'd almost rather always provide the driver registration, and then use #ifdefs in the body of that function to either provide a sane result or else report that the compilation environment was too old, rather than omit the support altogether. Maybe get Dan's opinion on this?
From the Xen test harness' point of view we'd like virsh capabilities to be accurate, FWIW.
Ian.