Hi Paolo, (+libvir-list) I'd like to report a regression introduced by this patch set: On 03/07/19 21:58, Paolo Bonzini wrote:
The following changes since commit 6cb4f6db4f4367faa33da85b15f75bbbd2bed2a6:
Merge remote-tracking branch 'remotes/cleber/tags/python-next-pull-request' into staging (2019-03-07 16:16:02 +0000)
are available in the Git repository at:
git://github.com/bonzini/qemu.git tags/for-upstream-kconfig
for you to fetch changes up to 576c3f2f16e7392e28cc9fe10d9a920d67d3645b:
kconfig: add documentation (2019-03-07 21:54:22 +0100)
---------------------------------------------------------------- Initial Kconfig work, excluding ARM and MIPS
----------------------------------------------------------------
I use "libvirt-daemon-4.5.0-10.el7.x86_64" at the moment. Here are the symptoms: (1) the output of the following command changes across this series: virsh domcapabilities qemu /opt/qemu-installed-optimized/bin/qemu-system-aarch64 aarch64 virt-4.0 as shown by the diff
@@ -92,6 +92,8 @@ <video supported='yes'> <enum name='modelType'> <value>vga</value> + <value>cirrus</value> + <value>vmvga</value> <value>virtio</value> </enum> </video> @@ -111,10 +113,7 @@ <value>scsi</value> </enum> <enum name='capsType'/> - <enum name='pciBackend'> - <value>default</value> - <value>vfio</value> - </enum> + <enum name='pciBackend'/> </hostdev> </devices> <features>
(2) given the following domain XML snippet, in a qemu (not KVM) aarch64 guest that I have,
<video> <model type='virtio' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </video>
the QEMU command line generated by libvirt changes:
- -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.4,addr=0x0 \ + -device virtio-vga,id=video0,max_outputs=1,bus=pci.4,addr=0x0 \
Perhaps this series causes (1), which in turn causes (2), or else this series causes both (1) and (2) independently of each other. I'm not sure about that. Either way, (2) is a problem, because virtio-vga is inappropriate for aarch64 guests (and the ArmVirtQemu platform firmware in edk2 won't even try to drive it -- a blank screen is the result). Now, I can't pinpoint an exact commit, because (after a *brutal* bisection) I get:
There are only 'skip'ped commits left to test. The first bad commit could be any of: a02c0edb35662de38d400f42b68845540669ca3d 03b348bdcbd1eda4ce097b2b84527dec774d80c4 d6e9c470fc91f75db1785f17a9d3567d5a27953d a7e23159074c9d774fb1e88357b778994a0c9365 bcb129b3154ba743f8e52c21c331a0dfcaee7c38 02017ee385ef574133c4a978d368640772978178 7c28b925b7e176b4e44ed05d23cf883561000546 1550b0e6bfe3ab6985e5ad75df1c528a0ca39468 e9947d18df97e6c6584f020cf9cc995404cc8061 8f01b41e1098d8cb9491fa3ea7bd59cf187a5bd7 9533dcdd416530a0d72140c122bf90517b6c81eb 32690c8bed5762518272876dcb6dd39a54f54fd1 c3a98aa54c734dcb7a36d193c6330d8f04d4bf8e ccf222a816d59af1318a7efb59c6b9c5578d1abf f349474920d80838ecea3d421531fdb0660b8740 2ac041c2c3d89691cda1657981c41fe4bc20244b e0e312f3525ad6ac18ba6633af29190dd9620cbc b42075bb77672616127c9452c0f836e757e9ce1a We cannot bisect more!
Here's how I built each step of the bisection: - "git clean -ffdx" and "git submodule deinit --all --force" on the source directory - create a new, pristine build directory - configure QEMU for out-of-tree build, in that directory - select the i386, x86_64, arm, and aarch64 targets (all softmmu) - report "skip" to git-bisect iff the build breaks, otherwise test the aarch64 emulator through libvirt, and report good/bad dependent on the test result. The bisection log is attached -- "git bisect replay" and "git bisect visualize" should tell the story better than the above dump of commit hashes. Basically: - The tree builds up to and including commit 82f5181777eb ("kconfig: introduce kconfig files", 2019-03-07), and that commit works fine as well. - Then the build breaks (starting with commit e0e312f3525a, "build: switch to Kconfig", 2019-03-07). - The tree becomes buildable again at commit b42075bb7767 ("virtio: express virtio dependencies with Kconfig", 2019-03-07), but at that point, the functionality has been regressed. Thanks, Laszlo