Test that we can resume source vm after [failed] migration, and bitmaps
are ok.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Before previous patch, iotest 169 was actually broken for the case
test_persistent__not_migbitmap__offline_shared, while formally
passing.
After migration log of vm_b had message:
qemu-system-x86_64: Could not reopen qcow2 layer: Bitmap already
exists: bitmap0
which means that invalidation failed and bs->drv = NULL.
It was because we've loaded bitmap twice: on open and on invalidation.
Add code to 169, to catch such fails.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: John Snow <jsnow@redhat.com>
This patch aims to bring the following behavior:
1. We don't load bitmaps, when started in inactive mode. It's the case
of incoming migration. In this case we wait for bitmaps migration
through migration channel (if 'dirty-bitmaps' capability is enabled) or
for invalidation (to load bitmaps from the image).
2. We don't remove persistent bitmaps on inactivation. Instead, we only
remove bitmaps after storing. This is the only way to restore bitmaps,
if we decided to resume source after [failed] migration with
'dirty-bitmaps' capability enabled (which means, that bitmaps were not
stored).
3. We load bitmaps on open and any invalidation, it's ok for all cases:
- normal open
- migration target invalidation with dirty-bitmaps capability
(bitmaps are migrating through migration channel, the are not
stored, so they should have IN_USE flag set and will be skipped
when loading. However, it would fail if bitmaps are read-only[1])
- migration target invalidation without dirty-bitmaps capability
(normal load of the bitmaps, if migrated with shared storage)
- source invalidation with dirty-bitmaps capability
(skip because IN_USE)
- source invalidation without dirty-bitmaps capability
(bitmaps were dropped, reload them)
[1]: to accurately handle this, migration of read-only bitmaps is
explicitly forbidden in this patch.
New mechanism for not storing bitmaps when migrate with dirty-bitmaps
capability is introduced: migration filed in BdrvDirtyBitmap.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: John Snow <jsnow@redhat.com>
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A, B, and C where
B started empty, then merge C into B, and B into A, an inaccurate
count meant that A did not get the contents of C.
In the worst case, we may falsely regard the bitmap as empty when
it has had new writes merged into it.
Fixes: be58721db
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20181002233314.30159-1-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Whether it's "locked" or "frozen", it's in use and should
not be allowed for the purposes of this operation.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20181002230218.13949-7-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
If the bitmap is frozen, we shouldn't touch it.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20181002230218.13949-6-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
We're not being consistent about this. If it's in use by an operation,
the user should not be able to change the behavior of that bitmap.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20181002230218.13949-5-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Similarly to merge, it's OK to allow clear operations on disabled
bitmaps, as this condition only means that they are not recording
new writes. We are free to clear it if the user requests it.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20181002230218.13949-4-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
In prior commits that made merge transactionable, we removed the
assertion that merge cannot operate on disabled bitmaps. In addition,
we want to make sure that we are prohibiting merges to "locked" bitmaps.
Use the new user_locked function to check.
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20181002230218.13949-3-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Instead of both frozen and qmp_locked checks, wrap it into one check.
frozen implies the bitmap is split in two (for backup), and shouldn't
be modified. qmp_locked implies it's being used by another operation,
like being exported over NBD. In both cases it means we shouldn't allow
the user to modify it in any meaningful way.
Replace any usages where we check both frozen and qmp_locked with the
new check.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20181002230218.13949-2-jsnow@redhat.com
[w/edits Suggested-By: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]
Signed-off-by: John Snow <jsnow@redhat.com>
This variable doesn't work as it should, because it is actually cleared
in qcow2_co_invalidate_cache() by memset(). Drop it, as the following
patch will introduce new behavior.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[Maintainer edit -- touched up error message. --js]
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
New action is like clean action: do the whole thing in .prepare and
undo in .abort. This behavior for bitmap-changing actions is needed
because backup job actions use bitmap in .prepare.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Rename block-dirty-bitmap-clear transaction handlers to reuse them for
x-block-dirty-bitmap-merge transaction in the following patch.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Add backup parameter to bdrv_merge_dirty_bitmap() to be used then with
bdrv_restore_dirty_bitmap() if it needed to restore the bitmap after
merge operation.
This is needed to implement bitmap merge transaction action in further
commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Use more generic names to reuse the function for bitmap merge in the
following commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Move checks from qmp_x_block_dirty_bitmap_merge() to
bdrv_merge_dirty_bitmap(), to share them with dirty bitmap merge
transaction action in future commit.
Note: for now, only qmp_x_block_dirty_bitmap_merge() calls
bdrv_merge_dirty_bitmap().
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
It is only an oversight that we don't allow incremental backup with
blockdev-backup. Add the bitmap argument which enables this.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20180830211605.13683-2-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
I spent way too much time trying to figure out why the emulated NVDIMM
was missing under Linux. In an effort to help others who might be looking
for these kinds of things in the future, include a hint.
Signed-off-by: Kees Cook <keescook@chromium.org>
Message-id: 20181018201351.GA25286@beast
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
According to qdev-properties.h, properties of pointer type should
be avoided, it seems a link type property is a good substitution.
Cc: Jan Kiszka <jan.kiszka@web.de>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Mao Zhongyi <maozhongyi@cmss.chinamobile.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20181022074050.19638-3-maozhongyi@cmss.chinamobile.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
See qemu_spice_add_display_interface(), the console index is also used
as channel id. So put that into the qxl->id field too.
In typical use cases (one primary qxl-vga device, optionally one or more
secondary qxl devices, no non-qxl display devices) this doesn't change
anything.
With this in place the qxl->id can not be used any more to figure
whenever a given device is primary (with vga compat mode) or secondary.
So add a bool to track this.
Cc: spice-devel@lists.freedesktop.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20181012114540.27829-1-kraxel@redhat.com
One fix for mingw build and some improvements in VM based testing, many thanks
to Paolo and Phil.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEEUAN8t5cGD3bwIa1WyjViTGqRccYFAlvTIXEQHGZhbXpAcmVk
aGF0LmNvbQAKCRDKNWJMapFxxlRqB/99FX5texTlvPy2yH8jC6eXWt1XzcqVc9Ei
TPHJ3LLR7EqjTBD/NCgvRzed4D0U2uRm8rXssujJPUnqt9hmlpNPzIEqLeV650hB
QBWWC8rrxzPMGKbQzBE0b/bbAaXW4KFsBXicmrTJz6MCN12S4yGwMJg3B7yAeXtp
2cVjhmoXiynx7qsWjKl8+hvSmCSMYvsfNygHGbFaLdr/CB8+ug/5fRg2yrhWz68U
emcjljgHRiZpKy8Kn0F0lKTPqKCYi0EVxoDk424c2Ag+oGZsxvhJMolPooOWVXCX
8bfmzyRR2aPi9m8bfp42+yqYYopD/ncr2zF65+6OYtTA2GfxiywG
=wIx1
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/famz/tags/testing-pull-request' into staging
Testing patches
One fix for mingw build and some improvements in VM based testing, many thanks
to Paolo and Phil.
# gpg: Signature made Fri 26 Oct 2018 15:15:13 BST
# gpg: using RSA key CA35624C6A9171C6
# gpg: Good signature from "Fam Zheng <famz@redhat.com>"
# Primary key fingerprint: 5003 7CB7 9706 0F76 F021 AD56 CA35 624C 6A91 71C6
* remotes/famz/tags/testing-pull-request:
tests/vm: Do not abuse parallelism when HOST != TARGET architecture
tests/vm: Do not use -enable-kvm if HOST != TARGET architecture
tests/vm: Let kvm_available() work in cross environments
tests/vm: Add a BaseVM::arch property
tests/vm: Display remaining seconds to wait for a VM to start
tests/vm: Do not use the -smp option with a single cpu
tests/vm: Do not abuse parallelism when KVM is not available
tests/vm: Extract the kvm_available() handy function
tests: docker: update test-mingw for GTK+ 2.0 removal
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJb0iQKAAoJENSXKoln91plUngH/icGvr5sa6JbT/4bDP20Wv7y
gwJ8Ax6kKDU4Z/JbBt+2diXVRrPXCF6xt/dvcaWCnxKyjIZN0i2azHv75jtMEA5t
+khdqqREzTZ8RiEI+u0r+OkSNJ3837O+ahQFdRxjqSDIScC8mcwW8h1md9ThjzbQ
yBhRvNo8QkXGGx9MCWZ7kUGkPnJDQnL0jGiFj0xhtyDSGXfnnOpUgpQKRWu5cQzl
Q7JKFPQgt676kd6UyG7f+xYw/a6uERmMBWp30CfN6bP4bPcdFHdUlgIM60VRAfhA
qYA4led5sWcuqmA96PoZIOc+05/8Q8NkgP+nYbXeMkW8/9QOCPa/30p7QayOpZA=
=F4up
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-oct-2018-part-3' into staging
MIPS queue for October 2018 - part 3
# gpg: Signature made Thu 25 Oct 2018 21:14:02 BST
# gpg: using RSA key D4972A8967F75A65
# gpg: Good signature from "Aleksandar Markovic <amarkovic@wavecomp.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65
* remotes/amarkovic/tags/mips-queue-oct-2018-part-3:
target/mips: Add disassembler support for nanoMIPS
target/mips: Implement emulation of nanoMIPS EVA instructions
target/mips: Add nanoMIPS CRC32 instruction pool
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The 'arch' property gives a hint on which architecture the guest image runs.
This can be use to select the correct QEMU binary path.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20181013004034.6968-6-f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Fam Zheng <famz@redhat.com>
--with-gtkabi does not exist anymore; remove it from the configure invocation.
Fixes: 89d85cde75
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1539886203-33670-1-git-send-email-pbonzini@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Add disassembler support for nanoMIPS.
Reviewed-by: Stefan Markovic <smarkovic@wavecomp.com>
Signed-off-by: Matthew Fortune <matthew.fortune@mips.com>
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Implement emulation of nanoMIPS EVA instructions. They are all
part of P.LS.E0 instruction pool, or one of its subpools.
Reviewed-by: Stefan Markovic <smarkovic@wavecomp.com>
Signed-off-by: Dimitrije Nikolic <dnikolic@wavecomp.com>
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
This pull request contains a handful of patches that have been floating
around various trees for a while but haven't made it upstream. These
patches all appear quite safe. They're all somewhat independent from
each other:
* One refactors our IRQ management function to allow multiple interrupts
to be raised an once. This patch has no functional difference.
* Cleaning up the op_helper/cpu_helper split. This patch has no
functional difference.
* Updates to various constants to keep them in sync with the latest ISA
specification and to remove some non-standard bits that snuck in.
* A fix for a memory leak in the PLIC driver.
* A fix to our device tree handling to avoid provinging a NULL string.
I've given this my standard test: building the port, booting a Fedora
root filesytem on the latest Linux tag, and then shutting down that
image. Essentially I'm just following the QEMU RISC-V wiki page's
instructions. Everything looks fine here.
We have a lot more outstanding patches so I'll definately be submitting
another PR for the soft freeze.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAlvHmPATHHBhbG1lckBk
YWJiZWx0LmNvbQAKCRDvTKFQLMurQforD/47/fuqbXlH2YZw5kNIuc/s0ULLOQFy
yqiBig350IzO5fHZuiPeWdLJjlB4HXgif5O7yFuePTppG+3dl8IOf+hreMopia7K
HaOG368vS1vQBDRhdw9OSDqeHipb9PF3zLoj0WWzngxrazg5WTyqX24k7Z/hCtco
dP1dY8rCCgWAgyNE3yJki1Y/+KnubX0L3kmpoFQYp0otXmMG/IA+5KRKal4Jml03
Z1puymvQNYyk+vI9gRPyjGQfbLeDn2jKghY0COad1u3okbfef9irDilmwCoFxhAA
qW6ThXKsyIbYF/uEhqjfcvh6SSIu/q3OtLKFmTGwzWI+Df6eumcdLDW07OLKUpY1
Xj7/6LqmeGfKMbe6b6JUfGwdf/4EpQ0byhGWBOjhj7CRyhtOryHrhBs15I3Fc57I
QlBKrQXmETOiW++CC+h2BqLwdnJ8nlelzSLb96FzFGrYcVRlnAlof+n+1sMQPWNy
quVyIWe4dZteJjJuTC1fnju4+LTH6sQCmhrvz10Jk1Hed1BYneww4D/bWc/Gzzgx
FiIQud+7WvUYilwhGmzWOcHxPa2NYJvmJErW8asLXOvERd33cfbcyxjj4GCVpe/F
vfZiubP+Pm95qXN31ahXB4SziFEw3I6IPLvCndFcLQSV2GvvF639xgcQEZ6m4xiV
LahYSgwjWSkPwQ==
=+IgM
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/riscv/tags/riscv-for-master-3.1-sf0' into staging
First RISC-V Patch Set for the 3.1 Soft Freeze
This pull request contains a handful of patches that have been floating
around various trees for a while but haven't made it upstream. These
patches all appear quite safe. They're all somewhat independent from
each other:
* One refactors our IRQ management function to allow multiple interrupts
to be raised an once. This patch has no functional difference.
* Cleaning up the op_helper/cpu_helper split. This patch has no
functional difference.
* Updates to various constants to keep them in sync with the latest ISA
specification and to remove some non-standard bits that snuck in.
* A fix for a memory leak in the PLIC driver.
* A fix to our device tree handling to avoid provinging a NULL string.
I've given this my standard test: building the port, booting a Fedora
root filesytem on the latest Linux tag, and then shutting down that
image. Essentially I'm just following the QEMU RISC-V wiki page's
instructions. Everything looks fine here.
We have a lot more outstanding patches so I'll definately be submitting
another PR for the soft freeze.
# gpg: Signature made Wed 17 Oct 2018 21:17:52 BST
# gpg: using RSA key EF4CA1502CCBAB41
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>"
# gpg: aka "Palmer Dabbelt <palmer@sifive.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
* remotes/riscv/tags/riscv-for-master-3.1-sf0:
RISC-V: Don't add NULL bootargs to device-tree
RISC-V: Add missing free for plic_hart_config
RISC-V: Update CSR and interrupt definitions
RISC-V: Move non-ops from op_helper to cpu_helper
RISC-V: Allow setting and clearing multiple irqs
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The XTS cipher mode performance is approximately doubled and test
coverage is improved.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJb0LRUAAoJEL6G67QVEE/fW0kQAKztZpe9TxQMIzQNlBtYJiUF
51Xit4GVj3jZ5An1HcxhfKxv3hbsKOdDifBw1I+F5c7Tfmid6M/8f9M+fZ0FmGiN
VsnkVNcckMbMck03C0llxigz24n3vxd8LvEQBR3ZA1sGAnWTSJNHfEmKZwh+5mX4
hT2WoFC2QGcwOyWUH5W9NtASbVgzr3/KWuCaluK/okmLHA+ENov3FetMWYPad848
FCjAvMLbC+S/AlkXwKTkn3L4+yow95yliyZHZXDiDS2QRP2u6fv39Q+0fYOayns1
cTgmggNNsRErsYMAGveX5+GoFfLtUdYDH9h6e4U77mxonZz9IL8iP8sFVZEUc3Md
syS3EPDQor+KBJF/opg0gR9IfY5cMoYUrW0huujX2uyOqQTl4yb0SAxzhPEP/gC7
BOW757WkRXMsNDZNdYAtHi+kp0PPA+zGl9QFTMFSQtRgnPHyO0gkLFgXFQartPcg
b6wpe+g+IwVdOzXjeYCJeP5WPD99pcxPsOcmHRfqopJq2fihm71czCFOg0uYjxZn
LwhLrAzge6/MrZFBHsCwpkkItJov0hKjUl5QJ0S4vEK4fRPawaBkcvR9QuTCo9Pb
xXdedxTKQYaBaXimV6ZsK4OpSZ/QR8FmwVeM33RUWzAz+SjtegzuvkXAA1Ic5XgI
nxnjod33d+jxrzPDrVMl
=K2kp
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/berrange/tags/qcrypto-next-pull-request' into staging
Improve performance of XTS cipher mode impl
The XTS cipher mode performance is approximately doubled and test
coverage is improved.
# gpg: Signature made Wed 24 Oct 2018 19:05:08 BST
# gpg: using RSA key BE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>"
# gpg: aka "Daniel P. Berrange <berrange@redhat.com>"
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF
* remotes/berrange/tags/qcrypto-next-pull-request:
crypto: add testing for unaligned buffers with XTS cipher mode
crypto: refactor XTS cipher mode test suite
crypto: annotate xts_tweak_encdec as inlineable
crypto: convert xts_mult_x to use xts_uint128 type
crypto: convert xts_tweak_encdec to use xts_uint128 type
crypto: introduce a xts_uint128 data type
crypto: remove code duplication in tweak encrypt/decrypt
crypto: expand algorithm coverage for cipher benchmark
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Validate that the XTS cipher mode will correctly operate with plain
text, cipher text and IV buffers that are not 64-bit aligned.
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current XTS test overloads two different tests in a single function
making the code a little hard to follow. Split it into distinct test
cases.
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Encouraging the compiler to inline xts_tweak_encdec increases the
performance for xts-aes-128 when built with gcrypt:
Encrypt: 545 MB/s -> 580 MB/s
Decrypt: 568 MB/s -> 602 MB/s
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>