On 9/12/18 2:53 AM, Xiong, Huan wrote:
> Hi,
>
> While running avocado-vt qemu virtio_console test, I observe this test
> failure:
>
> type_specific.io-github-autotest-qemu.virtio_console.spread_linear.specifiable.virtserialport.with_vm.interrupted_transfer.replug_recv.short:
> FAIL
>
> It failed because it passed device name, instead of device id, to device_del
> command:
>
> 2018-09-12 01:26:51,201 qemu_monitor L0334 DEBUG| (monitor
> avocado-vt-vm1.qmpmonitor1) Sending command 'device_del vs2'
> 2018-09-12 01:26:51,209 qemu_monitor L1690 DEBUG| Send command:
> {'execute': 'device_del vs2', 'id': 'qd1yhYb2'}
> 2018-09-12 01:26:51,215 virtio_console L0889 ERROR| interrupted_loopback
> failed with exception: QMP command 'device_del vs2' failed (arguments:
> None, error message: {u'class': u'CommandNotFound', u'desc': u'The command
> device_del vs2 has not been found'})
>
> Note "vs2" in above log is virtio serial port name defined in
> virtio_console.cfg. The device's id is a random string generated in
> VM.create(). See log below:
>
> MALLOC_PERTURB_=1 /usr/bin/qemu-system-aarch64 \
> ...
> -chardev
> socket,path=/var/tmp/avocado_Qppix1/virtio_port-vs2-20180911-221535-jIZMYhJ2,nowait,id=idZPwyah,server
> \
> -device virtserialport,id=idRvU3kn,name=vs2,chardev=idZPwyah \
> ...
>
> It seems to me the root cause of the issue is with the code in VM.create() in
> avocado-vt/virttest/qemu_vm.py. VM.create() first calls make_create_command()
> to create device information, which are later saved in self.devices, and
> generate QEMU command line and start QEMU process. Then when it continues to
> create VirtioConsole and VirtioSerial instances and add them to
> self.virtio_ports, it doesn't uses the device information saved in
> self.devices, but uses port id as port name instead. The above test retrieves
> port information from vm.virtio_ports and gets wrong id and hence QMP command
> failed (BTW, the 'CommandNotFound' error returned by QMP seems odd to me. I'd
> expect it be something like "Device not found". But I think that is a
> separate issue, which I'll look into).
>
> So, from my understanding, line 2915-2938 (the code that creates
> VirtioConsole and VirtioSerial instances and add them to self.virtio_ports)
> is the culprit. However, that part of the code has existed since 2012.
> So...am I missing something? I really can't see how it could work with the
> tp-qemu's virio-console test's default cfg file.
>
> Also note that I run the test on an aarch64 server running centos 7.4. But I
> don't think the test code in question is architecture specific.
>
> Thanks,
> Ray
>
>
Hi Ray,
I think you shouldn't underestimate bugs resilience - they can indeed
live in some code bases for decades :).
I believe that the best approach is to put together a PR with this
explanation, and the proposed changes, of course. Then people can check
the before/after by running the test you describe.
Let me know if you need help reviewing it.
Regards,
--
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[ 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 ]
