Implicit controllers may be dependent on device definitions altered in a post-parse callback. E.g., if a console device is defined without the target type, the type will be set in QEMU's callback. In the case of s390, this is virtio, which requires an implicit virtio-serial controller. By moving the implicit controller definition after the post-parse procssing this can be fixed. As Martin pointed out, implicit controllers should not need post-parsing, so the rearranging should not hurt. Probably this is only affecting the S390 virtio console anyway. V2 Changes: - Promoted from RFC to Patch Series - Added an qemuxml2xml testcase highlighting the issue: applying the first patch only will fail make check as the implicit controller is missing. Viktor Mihajlovski (2): S390: Testcase for console default target type (virtio) conf: Swap order of AddImplicitControllers and DomainDefPostParse src/conf/domain_conf.c | 8 +++---- .../qemuxml2argv-s390-defaultconsole.xml | 20 ++++++++++++++++ .../qemuxml2xmlout-balloon-device-auto.xml | 2 +- .../qemuxml2xmlout-channel-virtio-auto.xml | 2 +- .../qemuxml2xmlout-console-virtio.xml | 2 +- .../qemuxml2xmlout-disk-scsi-device-auto.xml | 2 +- .../qemuxml2xmlout-s390-defaultconsole.xml | 24 ++++++++++++++++++++ tests/qemuxml2xmltest.c | 2 ++ 8 files changed, 54 insertions(+), 8 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-defaultconsole.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-defaultconsole.xml -- 1.7.9.5 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list