Patchwork [1/4] configure: Add --enable-migration-from-qemu-kvm

login
register
mail settings
Submitter Cole Robinson
Date Feb. 19, 2013, 10:39 p.m.
Message ID <447a8e1d1d24ed89db081c9c912627335267bfbc.1361313340.git.crobinso@redhat.com>
Download mbox | patch
Permalink /patch/221931/
State New
Headers show

Comments

Cole Robinson - Feb. 19, 2013, 10:39 p.m.
This switch will turn on all the migration compat bits needed to
perform migration from qemu-kvm to qemu. It's just a stub for now.

This compat will break incoming migration from qemu < 1.3, but for
distros where qemu-kvm was the only shipped package for years it's
not a big loss (and I don't know any way to avoid it).

Signed-off-by: Cole Robinson <crobinso@redhat.com>
---
 configure | 10 ++++++++++
 1 file changed, 10 insertions(+)
Michael Tokarev - Feb. 20, 2013, 8:30 a.m.
20.02.2013 02:39, Cole Robinson wrote:
> This switch will turn on all the migration compat bits needed to
> perform migration from qemu-kvm to qemu. It's just a stub for now.
> 
> This compat will break incoming migration from qemu < 1.3, but for
> distros where qemu-kvm was the only shipped package for years it's
> not a big loss (and I don't know any way to avoid it).

Actually I think it is relatively easy to support migration from BOTH
qemu and qemu-kvm.  By adding a _runtime_ command-line switch (such as
--qemu-kvm-compat, which has been already mentioned in other context),
which modifies that migration stuff (machine definitions) in a reasonable
way.  It can be done based on this patchset I guess (when it will be
polished and proven to work well).  And after that is done, this
configure option can go away.

How do you guys think?

Thanks!

/mjt
Cole Robinson - Feb. 20, 2013, 5:48 p.m.
On 02/20/2013 03:30 AM, Michael Tokarev wrote:
> 20.02.2013 02:39, Cole Robinson wrote:
>> This switch will turn on all the migration compat bits needed to
>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>
>> This compat will break incoming migration from qemu < 1.3, but for
>> distros where qemu-kvm was the only shipped package for years it's
>> not a big loss (and I don't know any way to avoid it).
> 
> Actually I think it is relatively easy to support migration from BOTH
> qemu and qemu-kvm.  By adding a _runtime_ command-line switch (such as
> --qemu-kvm-compat, which has been already mentioned in other context),
> which modifies that migration stuff (machine definitions) in a reasonable
> way.  It can be done based on this patchset I guess (when it will be
> polished and proven to work well).  And after that is done, this
> configure option can go away.
> 
> How do you guys think?
> 

That solution works for me too.

Thanks,
Cole
Paolo Bonzini - Feb. 20, 2013, 6:13 p.m.
Il 20/02/2013 18:48, Cole Robinson ha scritto:
> > Actually I think it is relatively easy to support migration from BOTH
> > qemu and qemu-kvm.  By adding a _runtime_ command-line switch (such as
> > --qemu-kvm-compat, which has been already mentioned in other context),
> > which modifies that migration stuff (machine definitions) in a reasonable
> > way.  It can be done based on this patchset I guess (when it will be
> > polished and proven to work well).  And after that is done, this
> > configure option can go away.
> > 
> > How do you guys think?
> 
> That solution works for me too.

The configure option needs to remain for distros that need it for
backwards compatibility.  Adding support for migration from both can be
done on top.

Paolo
Cole Robinson - Feb. 20, 2013, 6:16 p.m.
On 02/20/2013 01:13 PM, Paolo Bonzini wrote:
> Il 20/02/2013 18:48, Cole Robinson ha scritto:
>>> Actually I think it is relatively easy to support migration from BOTH
>>> qemu and qemu-kvm.  By adding a _runtime_ command-line switch (such as
>>> --qemu-kvm-compat, which has been already mentioned in other context),
>>> which modifies that migration stuff (machine definitions) in a reasonable
>>> way.  It can be done based on this patchset I guess (when it will be
>>> polished and proven to work well).  And after that is done, this
>>> configure option can go away.
>>>
>>> How do you guys think?
>>
>> That solution works for me too.
> 
> The configure option needs to remain for distros that need it for
> backwards compatibility.  Adding support for migration from both can be
> done on top.
> 

Ah, true, I wasn't thinking about it fully. I figured having qemu-kvm be a
wrapper script that passed -qemu-kvm-compat would cover us, but in Fedora 18
even qemu-system-x86_64 uses the qemu-kvm migration format, so we will always
want the configure option.

- Cole
Anthony Liguori - Feb. 20, 2013, 8:26 p.m.
Cole Robinson <crobinso@redhat.com> writes:

> This switch will turn on all the migration compat bits needed to
> perform migration from qemu-kvm to qemu. It's just a stub for now.
>
> This compat will break incoming migration from qemu < 1.3, but for
> distros where qemu-kvm was the only shipped package for years it's
> not a big loss (and I don't know any way to avoid it).
>
> Signed-off-by: Cole Robinson <crobinso@redhat.com>

This can't be a build time option.  It's ugly and just reintroduces a fork.

I assume the issue with making it a run time option is that libvirt
would need to be updated?  Why can't qemu-kvm be a script wrapper that
passes a fixed flag?

Regards,

Anthony Liguori

> ---
>  configure | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/configure b/configure
> index bf5970f..296f488 100755
> --- a/configure
> +++ b/configure
> @@ -170,6 +170,7 @@ xfs=""
>  
>  vhost_net="no"
>  kvm="no"
> +migrate_from_kvm="no"
>  gprof="no"
>  debug_tcg="no"
>  debug="no"
> @@ -759,6 +760,8 @@ for opt do
>    ;;
>    --enable-kvm) kvm="yes"
>    ;;
> +  --enable-migration-from-qemu-kvm) migrate_from_kvm="yes"
> +  ;;
>    --disable-tcg-interpreter) tcg_interpreter="no"
>    ;;
>    --enable-tcg-interpreter) tcg_interpreter="yes"
> @@ -1087,6 +1090,9 @@ echo "  --enable-bluez           enable bluez stack connectivity"
>  echo "  --disable-slirp          disable SLIRP userspace network connectivity"
>  echo "  --disable-kvm            disable KVM acceleration support"
>  echo "  --enable-kvm             enable KVM acceleration support"
> +echo "  --enable-migration-from-qemu-kvm  Allow migration from qemu-kvm."
> +echo "                                    This will break migration from "
> +echo "                                    qemu < 1.3 in most cases"
>  echo "  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)"
>  echo "  --disable-nptl           disable usermode NPTL support"
>  echo "  --enable-nptl            enable usermode NPTL support"
> @@ -3334,6 +3340,7 @@ echo "Linux AIO support $linux_aio"
>  echo "ATTR/XATTR support $attr"
>  echo "Install blobs     $blobs"
>  echo "KVM support       $kvm"
> +echo "Migrate from qemu-kvm $migrate_from_kvm"
>  echo "TCG interpreter   $tcg_interpreter"
>  echo "fdt support       $fdt"
>  echo "preadv support    $preadv"
> @@ -3622,6 +3629,9 @@ fi
>  if test "$signalfd" = "yes" ; then
>    echo "CONFIG_SIGNALFD=y" >> $config_host_mak
>  fi
> +if test "$migrate_from_kvm" = "yes"; then
> +  echo "CONFIG_MIGRATE_FROM_QEMU_KVM=y" >> $config_host_mak
> +fi
>  if test "$tcg_interpreter" = "yes" ; then
>    echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak
>  fi
> -- 
> 1.8.1.2
Paolo Bonzini - Feb. 20, 2013, 8:45 p.m.
Il 20/02/2013 21:26, Anthony Liguori ha scritto:
> Cole Robinson <crobinso@redhat.com> writes:
> 
>> This switch will turn on all the migration compat bits needed to
>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>
>> This compat will break incoming migration from qemu < 1.3, but for
>> distros where qemu-kvm was the only shipped package for years it's
>> not a big loss (and I don't know any way to avoid it).
>>
>> Signed-off-by: Cole Robinson <crobinso@redhat.com>
> 
> This can't be a build time option.  It's ugly and just reintroduces a fork.

It is not a fork; it does not change the migration format of QEMU
itself, only the parsing of old VMState versions.  The importance of the
fork will dwindle over time, as the distros EOL the releases that used
qemu-kvm.

> I assume the issue with making it a run time option is that libvirt
> would need to be updated?

You cannot update libvirt, because whether to pass the flag or not
depends on the _source_ QEMU, which may be an ancient version we cannot
add any patch to.

> Why can't qemu-kvm be a script wrapper that
> passes a fixed flag?

See Cole's answer; qemu-system-* also used to be built from qemu-kvm
sources in Fedora.

Paolo
Cole Robinson - Feb. 20, 2013, 8:45 p.m.
On 02/20/2013 03:26 PM, Anthony Liguori wrote:
> Cole Robinson <crobinso@redhat.com> writes:
> 
>> This switch will turn on all the migration compat bits needed to
>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>
>> This compat will break incoming migration from qemu < 1.3, but for
>> distros where qemu-kvm was the only shipped package for years it's
>> not a big loss (and I don't know any way to avoid it).
>>
>> Signed-off-by: Cole Robinson <crobinso@redhat.com>
> 
> This can't be a build time option.  It's ugly and just reintroduces a fork.
> 
> I assume the issue with making it a run time option is that libvirt
> would need to be updated?  Why can't qemu-kvm be a script wrapper that
> passes a fixed flag?
> 

Fedora 18 ships only qemu-kvm-1.2. From that it builds qemu-kvm (with
accel=kvm default) and qemu-system-x86_64 (with accel=tcg default). Both still
have the migration incompatibility issues compared to plain qemu 1.2, like
cirrus mem=16MB.

So even if there was a cli option like -qemu-kvm-compat, in Fedora we would
want to enable it even for both qemu-kvm and qemu-system-x86_64.

Maybe add an option -qemu-kvm-compat=on|off, default to off, but add a
configure option to set default=on? We would set default=on in Fedora, but
users can still manually turn it off.

- Cole


> Regards,
> 
> Anthony Liguori
> 
>> ---
>>  configure | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/configure b/configure
>> index bf5970f..296f488 100755
>> --- a/configure
>> +++ b/configure
>> @@ -170,6 +170,7 @@ xfs=""
>>  
>>  vhost_net="no"
>>  kvm="no"
>> +migrate_from_kvm="no"
>>  gprof="no"
>>  debug_tcg="no"
>>  debug="no"
>> @@ -759,6 +760,8 @@ for opt do
>>    ;;
>>    --enable-kvm) kvm="yes"
>>    ;;
>> +  --enable-migration-from-qemu-kvm) migrate_from_kvm="yes"
>> +  ;;
>>    --disable-tcg-interpreter) tcg_interpreter="no"
>>    ;;
>>    --enable-tcg-interpreter) tcg_interpreter="yes"
>> @@ -1087,6 +1090,9 @@ echo "  --enable-bluez           enable bluez stack connectivity"
>>  echo "  --disable-slirp          disable SLIRP userspace network connectivity"
>>  echo "  --disable-kvm            disable KVM acceleration support"
>>  echo "  --enable-kvm             enable KVM acceleration support"
>> +echo "  --enable-migration-from-qemu-kvm  Allow migration from qemu-kvm."
>> +echo "                                    This will break migration from "
>> +echo "                                    qemu < 1.3 in most cases"
>>  echo "  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)"
>>  echo "  --disable-nptl           disable usermode NPTL support"
>>  echo "  --enable-nptl            enable usermode NPTL support"
>> @@ -3334,6 +3340,7 @@ echo "Linux AIO support $linux_aio"
>>  echo "ATTR/XATTR support $attr"
>>  echo "Install blobs     $blobs"
>>  echo "KVM support       $kvm"
>> +echo "Migrate from qemu-kvm $migrate_from_kvm"
>>  echo "TCG interpreter   $tcg_interpreter"
>>  echo "fdt support       $fdt"
>>  echo "preadv support    $preadv"
>> @@ -3622,6 +3629,9 @@ fi
>>  if test "$signalfd" = "yes" ; then
>>    echo "CONFIG_SIGNALFD=y" >> $config_host_mak
>>  fi
>> +if test "$migrate_from_kvm" = "yes"; then
>> +  echo "CONFIG_MIGRATE_FROM_QEMU_KVM=y" >> $config_host_mak
>> +fi
>>  if test "$tcg_interpreter" = "yes" ; then
>>    echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak
>>  fi
>> -- 
>> 1.8.1.2
Anthony Liguori - Feb. 20, 2013, 9:03 p.m.
Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 20/02/2013 21:26, Anthony Liguori ha scritto:
>> Cole Robinson <crobinso@redhat.com> writes:
>> 
>>> This switch will turn on all the migration compat bits needed to
>>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>>
>>> This compat will break incoming migration from qemu < 1.3, but for
>>> distros where qemu-kvm was the only shipped package for years it's
>>> not a big loss (and I don't know any way to avoid it).
>>>
>>> Signed-off-by: Cole Robinson <crobinso@redhat.com>
>> 
>> This can't be a build time option.  It's ugly and just reintroduces a fork.
>
> It is not a fork; it does not change the migration format of QEMU
> itself, only the parsing of old VMState versions.  The importance of the
> fork will dwindle over time, as the distros EOL the releases that used
> qemu-kvm.

Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever.
So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does
not set it.  It's a fork all within the same tree.

>> I assume the issue with making it a run time option is that libvirt
>> would need to be updated?
>
> You cannot update libvirt, because whether to pass the flag or not
> depends on the _source_ QEMU, which may be an ancient version we cannot
> add any patch to.
>
>> Why can't qemu-kvm be a script wrapper that
>> passes a fixed flag?
>
> See Cole's answer; qemu-system-* also used to be built from qemu-kvm
> sources in Fedora.

What about having something processed by readconfig that wasn't disabled
by -nodefaults?  Then we could make it a runtime option, but that's
configurable globally.  Then the distros can choose the default value in
the config file.

At least then, we can write unit tests with the option at run time,
don't need to sprinkle #ifdefs everywhere, etc.

Regards,

Anthony Liguori

>
> Paolo
Paolo Bonzini - Feb. 21, 2013, 7:44 a.m.
Il 20/02/2013 22:03, Anthony Liguori ha scritto:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> Il 20/02/2013 21:26, Anthony Liguori ha scritto:
>>> Cole Robinson <crobinso@redhat.com> writes:
>>>
>>>> This switch will turn on all the migration compat bits needed to
>>>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>>>
>>>> This compat will break incoming migration from qemu < 1.3, but for
>>>> distros where qemu-kvm was the only shipped package for years it's
>>>> not a big loss (and I don't know any way to avoid it).
>>>>
>>>> Signed-off-by: Cole Robinson <crobinso@redhat.com>
>>>
>>> This can't be a build time option.  It's ugly and just reintroduces a fork.
>>
>> It is not a fork; it does not change the migration format of QEMU
>> itself, only the parsing of old VMState versions.  The importance of the
>> fork will dwindle over time, as the distros EOL the releases that used
>> qemu-kvm.
> 
> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever.
> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does
> not set it.  It's a fork all within the same tree.

They will set it for a while.  For example, F18 is the last Fedora
release that had qemu-kvm < 1.3.0.  As soon as F18 goes end-of-life
(which is with F21), Fedora will not need to set the configure option
anymore.

Of course other distros will keep it for years rather than months, but
the idea is the same.

> What about having something processed by readconfig that wasn't disabled
> by -nodefaults?  Then we could make it a runtime option, but that's
> configurable globally.  Then the distros can choose the default value in
> the config file.
> 
> At least then, we can write unit tests with the option at run time,
> don't need to sprinkle #ifdefs everywhere, etc.

That would make sense, but it shouldn't block this patch.  What would
happen otherwise is that distros (who care about migration
compatibility) will just patch their code without even the #ifdefs.
It's already happening, these patches are in F18.

Paolo
Paolo Bonzini - Feb. 28, 2013, 11:21 a.m.
Il 21/02/2013 08:44, Paolo Bonzini ha scritto:
> Il 20/02/2013 22:03, Anthony Liguori ha scritto:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>>> Il 20/02/2013 21:26, Anthony Liguori ha scritto:
>>>> Cole Robinson <crobinso@redhat.com> writes:
>>>>
>>>>> This switch will turn on all the migration compat bits needed to
>>>>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>>>>
>>>>> This compat will break incoming migration from qemu < 1.3, but for
>>>>> distros where qemu-kvm was the only shipped package for years it's
>>>>> not a big loss (and I don't know any way to avoid it).
>>>>>
>>>>> Signed-off-by: Cole Robinson <crobinso@redhat.com>
>>>>
>>>> This can't be a build time option.  It's ugly and just reintroduces a fork.
>>>
>>> It is not a fork; it does not change the migration format of QEMU
>>> itself, only the parsing of old VMState versions.  The importance of the
>>> fork will dwindle over time, as the distros EOL the releases that used
>>> qemu-kvm.
>>
>> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever.
>> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does
>> not set it.  It's a fork all within the same tree.
> 
> They will set it for a while.  For example, F18 is the last Fedora
> release that had qemu-kvm < 1.3.0.  As soon as F18 goes end-of-life
> (which is with F21), Fedora will not need to set the configure option
> anymore.
> 
> Of course other distros will keep it for years rather than months, but
> the idea is the same.
> 
>> What about having something processed by readconfig that wasn't disabled
>> by -nodefaults?  Then we could make it a runtime option, but that's
>> configurable globally.  Then the distros can choose the default value in
>> the config file.
>>
>> At least then, we can write unit tests with the option at run time,
>> don't need to sprinkle #ifdefs everywhere, etc.
> 
> That would make sense, but it shouldn't block this patch.  What would
> happen otherwise is that distros (who care about migration
> compatibility) will just patch their code without even the #ifdefs.
> It's already happening, these patches are in F18.

Ping, where do we stand here?  Shall we discuss it next Tuesday?

Paolo
Anthony Liguori - Feb. 28, 2013, 1:06 p.m.
Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 21/02/2013 08:44, Paolo Bonzini ha scritto:
>> Il 20/02/2013 22:03, Anthony Liguori ha scritto:
>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>>
>>>> Il 20/02/2013 21:26, Anthony Liguori ha scritto:
>>>>> Cole Robinson <crobinso@redhat.com> writes:
>>>>>
>>>>>> This switch will turn on all the migration compat bits needed to
>>>>>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>>>>>
>>>>>> This compat will break incoming migration from qemu < 1.3, but for
>>>>>> distros where qemu-kvm was the only shipped package for years it's
>>>>>> not a big loss (and I don't know any way to avoid it).
>>>>>>
>>>>>> Signed-off-by: Cole Robinson <crobinso@redhat.com>
>>>>>
>>>>> This can't be a build time option.  It's ugly and just reintroduces a fork.
>>>>
>>>> It is not a fork; it does not change the migration format of QEMU
>>>> itself, only the parsing of old VMState versions.  The importance of the
>>>> fork will dwindle over time, as the distros EOL the releases that used
>>>> qemu-kvm.
>>>
>>> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever.
>>> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does
>>> not set it.  It's a fork all within the same tree.
>> 
>> They will set it for a while.  For example, F18 is the last Fedora
>> release that had qemu-kvm < 1.3.0.  As soon as F18 goes end-of-life
>> (which is with F21), Fedora will not need to set the configure option
>> anymore.
>> 
>> Of course other distros will keep it for years rather than months, but
>> the idea is the same.
>> 
>>> What about having something processed by readconfig that wasn't disabled
>>> by -nodefaults?  Then we could make it a runtime option, but that's
>>> configurable globally.  Then the distros can choose the default value in
>>> the config file.
>>>
>>> At least then, we can write unit tests with the option at run time,
>>> don't need to sprinkle #ifdefs everywhere, etc.
>> 
>> That would make sense, but it shouldn't block this patch.  What would
>> happen otherwise is that distros (who care about migration
>> compatibility) will just patch their code without even the #ifdefs.
>> It's already happening, these patches are in F18.
>
> Ping, where do we stand here?  Shall we discuss it next Tuesday?

My only requirement for this patch series is that it *also* be made to
be dynamically configurable.  This should be toggable with a command
line option and the default can be set by configure.

At least that makes it testable with make check.

Regards,

Anthony Liguori

>
> Paolo
Paolo Bonzini - Feb. 28, 2013, 1:11 p.m.
Il 28/02/2013 14:06, Anthony Liguori ha scritto:
>>> >> 
>>> >> That would make sense, but it shouldn't block this patch.  What would
>>> >> happen otherwise is that distros (who care about migration
>>> >> compatibility) will just patch their code without even the #ifdefs.
>>> >> It's already happening, these patches are in F18.
>> >
>> > Ping, where do we stand here?  Shall we discuss it next Tuesday?
> My only requirement for this patch series is that it *also* be made to
> be dynamically configurable.  This should be toggable with a command
> line option and the default can be set by configure.
> 
> At least that makes it testable with make check.

Can you remind me what migration tests we have in make check?

Paolo
Anthony Liguori - Feb. 28, 2013, 1:22 p.m.
Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 28/02/2013 14:06, Anthony Liguori ha scritto:
>>>> >> 
>>>> >> That would make sense, but it shouldn't block this patch.  What would
>>>> >> happen otherwise is that distros (who care about migration
>>>> >> compatibility) will just patch their code without even the #ifdefs.
>>>> >> It's already happening, these patches are in F18.
>>> >
>>> > Ping, where do we stand here?  Shall we discuss it next Tuesday?
>> My only requirement for this patch series is that it *also* be made to
>> be dynamically configurable.  This should be toggable with a command
>> line option and the default can be set by configure.
>> 
>> At least that makes it testable with make check.
>
> Can you remind me what migration tests we have in make check?

I've got fingerprinting tests in qemu-test that dumps all of the details
of PCI devices.  If this is a run time switch, I can add fingerprints
for qemu-kvm pretty trivially.

I'd like to add migration tests soon too.

This series doesn't just do migration stuff.  It changes the meaning of
pc-XXX.

Regards,

Anthony Liguori



>
> Paolo
Paolo Bonzini - Feb. 28, 2013, 3:02 p.m.
Il 28/02/2013 14:22, Anthony Liguori ha scritto:
>>> >> At least that makes it testable with make check.
>> >
>> > Can you remind me what migration tests we have in make check?
> I've got fingerprinting tests in qemu-test that dumps all of the details
> of PCI devices.  If this is a run time switch, I can add fingerprints
> for qemu-kvm pretty trivially.

That's a good point.  (BTW, funny how we were both thinking of
qemu-test, not "make check".  But the misunderstanding made my question
sound a bit snarky.  Sorry).

Paolo
Anthony Liguori - Feb. 28, 2013, 4:46 p.m.
Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 28/02/2013 14:22, Anthony Liguori ha scritto:
>>>> >> At least that makes it testable with make check.
>>> >
>>> > Can you remind me what migration tests we have in make check?
>> I've got fingerprinting tests in qemu-test that dumps all of the details
>> of PCI devices.  If this is a run time switch, I can add fingerprints
>> for qemu-kvm pretty trivially.
>
> That's a good point.  (BTW, funny how we were both thinking of
> qemu-test, not "make check".  But the misunderstanding made my question
> sound a bit snarky.  Sorry).

No problem :-)

I really do want to add migration tests too but my queue is a bit too
large right now.

Regards,

Anthony Liguori

>
> Paolo

Patch

diff --git a/configure b/configure
index bf5970f..296f488 100755
--- a/configure
+++ b/configure
@@ -170,6 +170,7 @@  xfs=""
 
 vhost_net="no"
 kvm="no"
+migrate_from_kvm="no"
 gprof="no"
 debug_tcg="no"
 debug="no"
@@ -759,6 +760,8 @@  for opt do
   ;;
   --enable-kvm) kvm="yes"
   ;;
+  --enable-migration-from-qemu-kvm) migrate_from_kvm="yes"
+  ;;
   --disable-tcg-interpreter) tcg_interpreter="no"
   ;;
   --enable-tcg-interpreter) tcg_interpreter="yes"
@@ -1087,6 +1090,9 @@  echo "  --enable-bluez           enable bluez stack connectivity"
 echo "  --disable-slirp          disable SLIRP userspace network connectivity"
 echo "  --disable-kvm            disable KVM acceleration support"
 echo "  --enable-kvm             enable KVM acceleration support"
+echo "  --enable-migration-from-qemu-kvm  Allow migration from qemu-kvm."
+echo "                                    This will break migration from "
+echo "                                    qemu < 1.3 in most cases"
 echo "  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)"
 echo "  --disable-nptl           disable usermode NPTL support"
 echo "  --enable-nptl            enable usermode NPTL support"
@@ -3334,6 +3340,7 @@  echo "Linux AIO support $linux_aio"
 echo "ATTR/XATTR support $attr"
 echo "Install blobs     $blobs"
 echo "KVM support       $kvm"
+echo "Migrate from qemu-kvm $migrate_from_kvm"
 echo "TCG interpreter   $tcg_interpreter"
 echo "fdt support       $fdt"
 echo "preadv support    $preadv"
@@ -3622,6 +3629,9 @@  fi
 if test "$signalfd" = "yes" ; then
   echo "CONFIG_SIGNALFD=y" >> $config_host_mak
 fi
+if test "$migrate_from_kvm" = "yes"; then
+  echo "CONFIG_MIGRATE_FROM_QEMU_KVM=y" >> $config_host_mak
+fi
 if test "$tcg_interpreter" = "yes" ; then
   echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak
 fi