Red Hat Bugzilla – Bug 1139507
wrong data-plane properties via info qtree to check if use iothread object syntax
Last modified: 2018-04-10 20:09:32 EDT
Description of problem: boot up KVM guest with virtio-blk data-plane using new iothread object syntax, but check the info qtree there was wrong data-plane properties. Version-Release number of selected component (if applicable): host info: # uname -r && rpm -q qemu-kvm-rhev 3.10.0-152.el7.x86_64 qemu-kvm-rhev-2.1.0-3.el7.x86_64 guest info: 3.10.0-152.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.boot up KVM guest with virtio-blk data-plane using new iothread object syntax. e.g:...-object iothread,id=iothread0 -drive file=/home/my-data-disk.qcow2,if=none,id=drive-data-disk0,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,readonly=on,snapshot=on -device virtio-blk-pci,drive=drive-data-disk0,id=data-disk0,iothread=iothread0,bus=pci.0,addr=0x7 2.check the info qtree. (qemu) info qtree Actual results: after step 2, it show that config-wce = true and x-data-plane = false info qtree. (qemu) info qtree ... dev: virtio-blk-pci, id "data-disk0" class = 0 (0x0) ioeventfd = true vectors = 2 (0x2) indirect_desc = true event_idx = true addr = 07.0 romfile = "" rombar = 1 (0x1) multifunction = false command_serr_enable = true class SCSI controller, addr 00:07.0, pci id 1af4:1001 (sub 1af4:0002) bar 0: i/o at 0xffffffffffffffff [0x3e] bar 1: mem at 0xffffffffffffffff [0xffe] bus: virtio-bus type virtio-pci-bus dev: virtio-blk-device, id "" drive = "drive-data-disk0" logical_block_size = 512 (0x200) physical_block_size = 512 (0x200) min_io_size = 0 (0x0) opt_io_size = 0 (0x0) bootindex = -1 (0xffffffffffffffff) discard_granularity = 4294967295 (0xffffffff) cyls = 2080 (0x820) heads = 16 (0x10) secs = 63 (0x3f) serial = "" config-wce = true scsi = true x-data-plane = false ... Expected results: it should be config-wce = false and x-data-plane = true if we enable the data-plane. Additional info: Also tried the old virtio-blk data-plane syntax which did not hit it. e.g:...-drive if=none,cache=none,aio=native,format=raw,file=/home/my-data-disk.raw,id=drive0 -device virtio-blk-pci,drive=drive0,scsi=off,config-wce=off,x-data-plane=on,id=data-disk (qemu) info qtree ... dev: virtio-blk-pci, id "data-disk" class = 0 (0x0) ioeventfd = true vectors = 2 (0x2) indirect_desc = true event_idx = true addr = 07.0 romfile = "" rombar = 1 (0x1) multifunction = false command_serr_enable = true class SCSI controller, addr 00:07.0, pci id 1af4:1001 (sub 1af4:0002) bar 0: i/o at 0xffffffffffffffff [0x3e] bar 1: mem at 0xffffffffffffffff [0xffe] bus: virtio-bus type virtio-pci-bus dev: virtio-blk-device, id "" drive = "drive0" logical_block_size = 512 (0x200) physical_block_size = 512 (0x200) min_io_size = 0 (0x0) opt_io_size = 0 (0x0) bootindex = -1 (0xffffffffffffffff) discard_granularity = 4294967295 (0xffffffff) cyls = 2080 (0x820) heads = 16 (0x10) secs = 63 (0x3f) serial = "" config-wce = false scsi = false x-data-plane = true ...
QEMU 2.1 supports config-wce=true with dataplane, so that part is not applicable anymore. x-data-plane means that there is a special iothread for this disk, unrelated to those created with -object. So it's ok that it is false. The bug is that the iothread property doesn't appear in "info qtree", but this is not easy to solve right now.
As Paolo explained in Comment 1, the output is expected. x-data-plane = true is different from using -device virtio-blk-pci,iothread=iothread0. We should make an effort to reflect QOM properties into the info qtree output. The reason iothread=iothread0 is not displayed is because it's not a qdev property but a QOM link property. These are implementation details of QEMU but it's worth keeping this bug open to remind us that this should be added in a future version.
Defer to RHEL 7.2. See Comment 2 for explanation.
Deferring to 7.3.
Moving to RHEL 7.4. It would be nice to fix but end users are not exposed to this problem.
Moving to RHEL 7.5. This bug doesn't affect libvirt users but is a reminder that "info qtree" output should be improved upstream.
I've posted a related series to qemu-devel mailing list: [PATCH 0/7] qdev: Introduce DEFINE_PROP_LINK Stefan: I'd be okay with taking over this BZ if upstream maintainers ack the above idea.
(In reply to Fam Zheng from comment #11) > I've posted a related series to qemu-devel mailing list: > > [PATCH 0/7] qdev: Introduce DEFINE_PROP_LINK > > Stefan: I'd be okay with taking over this BZ if upstream maintainers ack the > above idea. That would be great! I haven't looked at this for a while.
Example: $ (echo info qtree; echo q;) | qemu-system-x86_64 -object iothread,id=iot0 -device virtio-scsi,iothread=iot0 -monitor stdio | grep -C 10 iothread bar 1: mem at 0xffffffffffffffff [0xffe] bar 4: mem at 0xffffffffffffffff [0x3ffe] bus: virtio-bus type virtio-pci-bus dev: virtio-scsi-device, id "" num_queues = 1 (0x1) max_sectors = 65535 (0xffff) cmd_per_lun = 128 (0x80) hotplug = true param_change = true iothread = "/objects/iot0" indirect_desc = true event_idx = true notify_on_empty = true any_layout = true iommu_platform = false bus: scsi.0 type SCSI dev: PIIX4_PM, id "" smb_io_base = 45312 (0xb100) disable_s3 = 0 (0x0)
Verified, the problem has been resolved, set its status to "Verified". Test steps： 1.Start guest with qemu cmds: /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -machine pc \ -nodefaults \ -vga std \ -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/monitor-qmpmonitor1-20170124-161452-WcepYpO8,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -object iothread,id=iothread0 \ -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=03,iothread=iothread0 \ -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/rhel74-64-virtio.qcow2 \ -device scsi-hd,id=image1,drive=drive_image1,bus=scsi0.0,lun=0 \ -device virtio-net-pci,mac=9a:b2:b3:b4:b5:b6,id=iduCv1Ln,vectors=4,netdev=idKgexFk,bus=pci.0,addr=05 \ -netdev tap,id=idKgexFk,vhost=on \ -m 4096 \ -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \ -cpu host \ -vnc :1 \ -rtc base=localtime,clock=host,driftfix=slew \ -enable-kvm \ -monitor stdio \ #-device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=04 \ #-drive id=data_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/t1.qcow2,serial=TARGET_DISK0 \ #-device scsi-hd,id=data1,drive=data_image1,bus=scsi1.0,lun=0 \ 2.Check data plane info in qtree (qemu)info qtree bus: virtio-bus type virtio-pci-bus dev: virtio-scsi-device, id "" num_queues = 1 (0x1) max_sectors = 65535 (0xffff) cmd_per_lun = 128 (0x80) hotplug = true param_change = true iothread = "/objects/iothread0" indirect_desc = true event_idx = true notify_on_empty = true any_layout = true iommu_platform = false __com.redhat_rhel6_ctrl_guest_workaround = false bus: scsi0.0 type SCSI dev: scsi-hd, id "image1" drive = "drive_image1" logical_block_size = 512 (0x200) physical_block_size = 512 (0x200) min_io_size = 0 (0x0) opt_io_size = 0 (0x0) discard_granularity = 4096 (0x1000) write-cache = "auto" share-rw = false rerror = "auto" werror = "auto" ver = "2.5+" serial = "" vendor = "QEMU" product = "QEMU HARDDISK" removable = false dpofua = false wwn = 0 (0x0) port_wwn = 0 (0x0) port_index = 0 (0x0) max_unmap_size = 1073741824 (0x40000000) max_io_size = 2147483647 (0x7fffffff) cyls = 16383 (0x3fff) heads = 16 (0x10) secs = 63 (0x3f) channel = 0 (0x0) scsi-id = 0 (0x0) lun = 0 (0x0)
Test version: kernel version:3.10.0-718.el7.x86_64 qemu-kvm-rhev version: qemu-kvm-rhev-2.10.0-1.el7.x86_64
Verified in kernel:3.10.0-844.el7.x86_64 + qemu-kvm-rhev:qemu-kvm-rhev-2.10.0-19.el7.x86_64, don't have this issue.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:1104