Comment 11 for bug 1570195

Since ftrace failed me I switched to gdb via the qemu -s parameter.

Debuginfo and source of guest kernel on the Host:
sudo apt-get install linux-tools-4.4.0-18-dbgsym
sudo pull-lp-source linux 4.4.0-18.34
sudo mkdir -p /build/linux-XwpX40; sudo ln -s /home/ubuntu/linux-4.4.0 /build/linux-XwpX40/linux-4.4.0

Edit that into the guest and restart:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <qemu:commandline>
    <qemu:arg value='-s'/>
  </qemu:commandline>
gdb /usr/lib/debug/boot/vmlinux-4.4.0-18-generic

b dev_ethtool
b ethtool_set_channels
b virtnet_set_channels
b virtnet_set_queues

Then on the guest run
sudo /usr/bin/testpmd --pci-blacklist 0000:00:03.0 --socket-mem 2048 -- --interactive --total-num-mbufs=2048

Attach gdb with
target remote :1234

Then on the guest trigger the bug
sudo ethtool -L eth1 combined 3

It is really "hanging" on that virtnet_send_command called from there.
As expected the loop never breaks.

1010 /* Spin for a response, the kick causes an ioport write, trapping
1011 * into the hypervisor, so the request should be handled immediately.
1012 */
1013 while (!virtqueue_get_buf(vi->cvq, &tmp) &&
1014 !virtqueue_is_broken(vi->cvq))
1015 cpu_relax();
1016
1017 return vi->ctrl_status == VIRTIO_NET_OK;
(gdb) n
1014 !virtqueue_is_broken(vi->cvq))
(gdb)
1013 while (!virtqueue_get_buf(vi->cvq, &tmp) &&
(gdb)
1015 cpu_relax();
[...]
Infinite loop.