On 2012-07-24 22:20, Nicholas A. Bellinger wrote:
> On Tue, 2012-07-24 at 09:57 +0200, Jan Kiszka wrote:
>> On 2012-07-24 09:42, Nicholas A. Bellinger wrote:
>>> Hi Anthony, Stefan & QEMU folks,
>>>
>
> <SNIP>
>
>>> However, thus far I've not been able to get virtio-scsi <-> tcm_vhost
>>> I/O to actually work against the latest qemu.git/master..
>>>
>>> So while doing a (manual) bisection w/ this series to track down the
>>> issue with qemu/master, I managed to run across something else.. With
>>> the vhost-scsi series applied, everything is working as expected up
>>> until the following commit:
>>>
>>> commit 1523ed9e1d46b0b54540049d491475ccac7e6421
>>> Author: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
>>> Date: Thu May 17 10:32:39 2012 -0300
>>>
>>> virtio/vhost: Add support for KVM in-kernel MSI injection
>>>
>>>
>>> This commit ends up triggering the following assert immediately after
>>> starting qemu with virtio-scsi <-> tcm_vhost:
>>>
>>> qemu-system-x86_64: /usr/src/qemu.git/hw/msix.c:515:
>>> msix_unset_vector_notifiers: Assertion `dev->msix_vector_use_notifier &&
>>> dev->msix_vector_release_notifier' failed.
>>>
>>> OK, so adding the following hack allows me to boot:
>>>
>>> diff --git a/hw/msix.c b/hw/msix.c
>>> index 59c7a83..6036909 100644
>>> --- a/hw/msix.c
>>> +++ b/hw/msix.c
>>> @@ -511,6 +511,11 @@ void msix_unset_vector_notifiers(PCIDevice *dev)
>>> {
>>> int vector;
>>>
>>> + if (!dev->msix_vector_use_notifier && !dev->msix_vector_release_notifier) {
>>> + printf("Hit NULL msix_unset_vector_notifiers for: %s\n", dev->name);
>>> + return;
>>> + }
>>> +
>>> assert(dev->msix_vector_use_notifier &&
>>> dev->msix_vector_release_notifier);
>>>
>>> --
>>
>> Can you post a backtrace from gdb?
>>
>
> Sure, w/o the above patch the backtrace with commit 1523ed9e1d looks
> like the following:
>
> (gdb) run
> Starting program: /usr/src/qemu.git/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 2048 -serial file:/tmp/vhost-serial.txt -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 -vhost-scsi id=vhost-scsi0,wwpn=naa.600140579ad21088,tpgt=1 -device virtio-scsi-pci,vhost-scsi=vhost-scsi0,event_idx=off
> [Thread debugging using libthread_db enabled]
> wwpn = "vhost-scsi0" tpgt = "1"
> [New Thread 0x7ffff45f8700 (LWP 26508)]
> [New Thread 0x7ffff3bf6700 (LWP 26509)]
> [New Thread 0x7ffff33f5700 (LWP 26510)]
> vhost_scsi_stop
> Failed to clear endpoint
> qemu-system-x86_64: /usr/src/qemu.git/hw/msix.c:515: msix_unset_vector_notifiers: Assertion `dev->msix_vector_use_notifier && dev->msix_vector_release_notifier' failed.
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff5e8b165 in raise () from /lib/libc.so.6
> (gdb) bt
> #0 0x00007ffff5e8b165 in raise () from /lib/libc.so.6
> #1 0x00007ffff5e8df70 in abort () from /lib/libc.so.6
> #2 0x00007ffff5e842b1 in __assert_fail () from /lib/libc.so.6
> #3 0x00000000004a84a1 in msix_unset_vector_notifiers (dev=0x1463a70) at /usr/src/qemu.git/hw/msix.c:514
> #4 0x00000000004d2865 in virtio_pci_set_guest_notifiers (opaque=0x6788, assign=136)
There are obviously random parameter values submitted. This is broken.
> at /usr/src/qemu.git/hw/virtio-pci.c:703
> #5 0x000000000062955f in vhost_dev_stop (hdev=0x126c8a8, vdev=0x1465220) at /usr/src/qemu.git/hw/vhost.c:954
> #6 0x0000000000628989 in vhost_scsi_stop (vs=0x126c890, vdev=0x1465220) at /usr/src/qemu.git/hw/vhost-scsi.c:115
And I suspect this is the origin: A stop on an unstarted vhost device.
Am I right?
But such a bug may not yet explain a performance regression - unless the
spurious stop creates a state that slows things down later on.
Did you check that direct MSI-X vector injection is actually in use
later on?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
