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