
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@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