On 04/13/2016 11:14 AM, Martin Kletzander wrote:
v5:
- Just a rebase, plus v4 had some hunk in that didn't belong there so
this one's cleaner to look at
-
https://www.redhat.com/archives/libvir-list/2016-March/msg01436.html
v4:
- Added test case without "heads="
- Don't consolidate 'size_t i, j' declarations
v3:
- rebase on top of current master in order to cleanly apply
-
https://www.redhat.com/archives/libvir-list/2016-March/msg01198.html
v2:
- don't change heads when migrating
-
https://www.redhat.com/archives/libvir-list/2016-March/msg00811.html
v1:
-
https://www.redhat.com/archives/libvir-list/2016-March/msg00410.html
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1283207
Martin Kletzander (2):
qemu: Check for qxl's max_outputs parameter
qemu: Add support to QXL's max_outputs parameter
src/qemu/qemu_capabilities.c | 5 ++
src/qemu/qemu_capabilities.h | 4 ++
src/qemu/qemu_command.c | 8 +++
src/qemu/qemu_migration.c | 64 ++++++++++++++++++++--
.../qemuxml2argv-video-qxl-heads.args | 28 ++++++++++
.../qemuxml2argv-video-qxl-heads.xml | 47 ++++++++++++++++
.../qemuxml2argv-video-qxl-noheads.args | 24 ++++++++
.../qemuxml2argv-video-qxl-noheads.xml | 39 +++++++++++++
tests/qemuxml2argvtest.c | 16 ++++++
.../qemuxml2xmlout-video-qxl-heads.xml | 47 ++++++++++++++++
.../qemuxml2xmlout-video-qxl-noheads.xml | 39 +++++++++++++
tests/qemuxml2xmltest.c | 3 +
12 files changed, 319 insertions(+), 5 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-heads.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-heads.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-noheads.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-noheads.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-video-qxl-heads.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-video-qxl-noheads.xml
--
2.8.1
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Been sitting on list for a while ....
Obviously I think you know you have to update to top of tree
Would be nice to perhaps add a few intro comments to
qemuMigratePrepareDomain at least with respect to what the purpose is
and what "could" be done in the future in the code. Looks like to me
it's now a shim to qemuProcessPrepareDomain to take care of any of those
"inconsistencies" between what can be supported in/on the new system
(perhaps could work in the opposite direction too ;-))... When I'm
reading code, I'm not necessarily looking at the commit message that
added which may have that information.
I think you could also update the commit message to point at the
previous code that was reverted to help understand the history.
ACK for the concept - looks like things are OK to me.
John