[libvirt] [PATCH 7/7] qemu: Support newer ivshmem and prefer that over the legacy one

Martin Kletzander mkletzan at redhat.com
Thu Aug 11 11:17:43 UTC 2016


On Thu, Aug 11, 2016 at 09:27:47AM +0100, Daniel P. Berrange wrote:
>On Wed, Aug 10, 2016 at 01:50:11PM +0200, Martin Kletzander wrote:
>> QEMU added support for ivshmem-plain and ivshmem-doorbell.  Those are
>> reworked varians of legacy ivshmem that are compatible, but have sane
>> specification and handling.
>>
>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1347049
>>
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> ---
>>  src/qemu/qemu_command.c                            | 66 ++++++++++++++++++++--
>>  .../qemuxml2argv-shmem-plain-doorbell.args         | 42 ++++++++++++++
>>  .../qemuxml2argv-shmem-plain-doorbell.xml          | 54 ++++++++++++++++++
>>  tests/qemuxml2argvtest.c                           |  3 +
>>  4 files changed, 161 insertions(+), 4 deletions(-)
>>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.args
>>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.xml
>
>Isn't this going to break migration compatibility. eg if someone
>has a guest running on a QEMU with ivshmem, which also has the
>ivshmem-plain, then when they upgrade libvirt their guest will
>guest the different device, which has different migration ABI ?
>
>Or is there a blocker that entirely prevents migration with
>ivshmem, making it a non-issue ?
>

ivshmem migration is forbidden if the role is "master".  It now makes
sense with the new ivshmem-plain, but didn't make much sense with the
old one, so we didn't add support for it.  Thanks to that we can make
old ones just role=peer and the new ones to role=master (which are the
qemu defaults anyway) and then we can check that in the ABI stability
check.  I forgot to do that, good point.  However, I need to make sure
that migration works from legacy to ivshmem-plain, otherwise we'd need
to either add a model (I wouldn't like that) or forbid migration based
on qemu capabilities and migration cookie flag.  I'll have a look at
that.


>Regards,
>Daniel
>--
>|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org              -o-             http://virt-manager.org :|
>|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>
>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160811/75f6e95e/attachment-0001.sig>


More information about the libvir-list mailing list