From: Paolo Bonzini <pbonzini@redhat.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, Asias He <asias@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
Gleb Natapov <gleb@redhat.com>
Subject: Re: [Qemu-devel] qemu seabios issue with vhost-scsi
Date: Thu, 23 May 2013 18:19:35 +0200 [thread overview]
Message-ID: <519E4197.7030605@redhat.com> (raw)
In-Reply-To: <519E3FCE.5040401@us.ibm.com>
Il 23/05/2013 18:11, Badari Pulavarty ha scritto:
> On 05/23/2013 08:30 AM, Paolo Bonzini wrote:
>> Il 23/05/2013 17:27, Asias He ha scritto:
>>> On Thu, May 23, 2013 at 04:58:05PM +0200, Paolo Bonzini wrote:
>>>> Il 23/05/2013 16:48, Badari Pulavarty ha scritto:
>>>>>> The common virtio-scsi code in QEMU should guard against this. In
>>>>>> virtio-blk data plane I hit a similar case and ended up starting the
>>>>>> data plane thread (equivalent to vhost here) *before* the status
>>>>>> register is set to DRIVER_OK.
>>>>> Thats exactly what my debug in vhost_scsi_set_status() shows.
>>>>>
>>>>> set status started 0 val 0
>>>>> set status started 0 val 0
>>>>> set status started 0 val 0
>>>>> set status started 0 val 0
>>>>> set status started 0 val 0
>>>>> set status started 0 val 3
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>
>>>>> We never got a chance to call vhost_scsi_start() as we are waiting
>>>>> for DRIVER_OK.
>>> Reproduced the SIGSEGV and verified that replacing the bios.bin with the
>>> one from seabios.git makes the guest boot.
>> This should fix it:
>>
>> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
>> index 08dd3f3..3139355 100644
>> --- a/hw/scsi/virtio-scsi.c
>> +++ b/hw/scsi/virtio-scsi.c
>> @@ -266,7 +266,7 @@ fail:
>>
>> static void virtio_scsi_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
>> {
>> - VirtIOSCSI *s = (VirtIOSCSI *)vdev;
>> + VirtIOSCSI *s = VIRTIO_SCSI(vdev);
>> VirtIOSCSIReq *req;
>>
>> while ((req = virtio_scsi_pop_req(s, vq))) {
>> @@ -347,9 +347,8 @@ static void virtio_scsi_fail_cmd_req(VirtIOSCSIReq
>> *req)
>>
>> static void virtio_scsi_handle_cmd(VirtIODevice *vdev, VirtQueue *vq)
>> {
>> - /* use non-QOM casts in the data path */
>> - VirtIOSCSI *s = (VirtIOSCSI *)vdev;
>> - VirtIOSCSICommon *vs = &s->parent_obj;
>> + VirtIOSCSI *s = VIRTIO_SCSI(vdev);
>> + VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
>>
>> VirtIOSCSIReq *req;
>> int n;
>>
>> Paolo
>>
> Hmm.. Not quite..
If that is with the old SeaBIOS, then SIGABRT is intended. :) The guest
is buggy, the problem in QEMU only lies in _how_ it fails.
Paolo
> (gdb) run -cpu qemu64 --enable-kvm -m 4096 -drive
> file=/var/lib/libvirt/images/lnx.img,if=ide,cache=writethrough -device
> vhost-scsi-pci,wwpn=naa.6001405bd4e8476d,event_idx=off -vnc :10 -boot d
> Starting program: /root/qemu/x86_64-softmmu/qemu-system-x86_64 -cpu
> qemu64 --enable-kvm -m 4096 -drive
> file=/var/lib/libvirt/images/lnx.img,if=ide,cache=writethrough -device
> vhost-scsi-pci,wwpn=naa.6001405bd4e8476d,event_idx=off -vnc :10 -boot d
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7ffff7ffa000
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7ffff1c1c700 (LWP 2458)]
> [New Thread 0x7ffff1239700 (LWP 2459)]
> [New Thread 0x7fffeb7ff700 (LWP 2462)]
> set status started 0 val 0
> set status started 0 val 0
> set status started 0 val 0
> set status started 0 val 0
> set status started 0 val 0
> set status started 0 val 3
> /root/qemu/hw/scsi/virtio-scsi.c:356:virtio_scsi_handle_cmd: Object
> 0x5555565aca88 is not an instance of type virtio-scsi-device
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7ffff1239700 (LWP 2459)]
> 0x00007ffff5cf18a5 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64
> cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64
> cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64
> cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64
> glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6.x86_64
> gnutls-2.8.5-10.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64
> krb5-libs-1.10.3-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64
> libcurl-7.19.7-35.el6.x86_64 libgcrypt-1.4.5-9.el6_2.2.x86_64
> libgpg-error-1.7-4.el6.x86_64 libidn-1.18-2.el6.x86_64
> libpng-1.2.49-1.el6_2.x86_64 libselinux-2.0.94-5.3.el6.x86_64
> libssh2-1.4.2-1.el6.x86_64 libtasn1-2.3-3.el6_2.1.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 nspr-4.9.2-1.el6.x86_64
> nss-3.14.0.0-12.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64
> nss-util-3.14.0.0-2.el6.x86_64 openldap-2.4.23-31.el6.x86_64
> openssl-1.0.0-27.el6.x86_64 pixman-0.26.2-4.el6.x86_64
> zlib-1.2.3-29.el6.x86_64
> (gdb) bt
> #0 0x00007ffff5cf18a5 in raise () from /lib64/libc.so.6
> #1 0x00007ffff5cf3085 in abort () from /lib64/libc.so.6
> #2 0x00005555557230d0 in object_dynamic_cast_assert
> (obj=0x5555565aca88, typename=0x5555558a56e5 "virtio-scsi-device",
> file=0x5555558bda30 "/root/qemu/hw/scsi/virtio-scsi.c", line=356,
> func=<value optimized out>) at qom/object.c:456
> #3 0x00005555557a5ef1 in virtio_scsi_handle_cmd (vdev=0x5555565aca88,
> vq=0x5555565d2160) at /root/qemu/hw/scsi/virtio-scsi.c:356
> #4 0x00005555557b3a60 in access_with_adjusted_size (addr=16,
> value=0x7ffff1238b78, size=2, access_size_min=<value optimized out>,
> access_size_max=<value optimized out>, access=
> 0x5555557b51d0 <memory_region_write_accessor>,
> opaque=0x5555565ac940) at /root/qemu/memory.c:364
> #5 0x00005555557b408b in memory_region_iorange_write (iorange=<value
> optimized out>, offset=<value optimized out>, width=<value optimized
> out>, data=2) at /root/qemu/memory.c:439
> #6 0x00005555557b2ff6 in kvm_handle_io (env=0x555556521af0) at
> /root/qemu/kvm-all.c:1485
> #7 kvm_cpu_exec (env=0x555556521af0) at /root/qemu/kvm-all.c:1634
> #8 0x000055555576148e in qemu_kvm_cpu_thread_fn (arg=0x555556521af0) at
> /root/qemu/cpus.c:759
> #9 0x00007ffff6059851 in start_thread () from /lib64/libpthread.so.0
> #10 0x00007ffff5da790d in clone () from /lib64/libc.so.6
>
next prev parent reply other threads:[~2013-05-23 16:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 0:36 [Qemu-devel] qemu seabios issue with vhost-scsi Badari
2013-05-23 0:53 ` Asias He
2013-05-23 9:48 ` Gleb Natapov
2013-05-23 13:32 ` Stefan Hajnoczi
2013-05-23 14:48 ` Badari Pulavarty
2013-05-23 14:58 ` Paolo Bonzini
2013-05-23 15:27 ` Asias He
2013-05-23 15:30 ` Paolo Bonzini
2013-05-23 16:11 ` Badari Pulavarty
2013-05-23 16:19 ` Paolo Bonzini [this message]
2013-05-23 16:38 ` Badari Pulavarty
2013-05-23 16:47 ` Paolo Bonzini
2013-05-23 17:18 ` Stefan Hajnoczi
2013-05-23 17:31 ` Paolo Bonzini
2013-05-24 0:02 ` Asias He
2013-05-23 16:08 ` Badari Pulavarty
2013-05-23 12:45 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519E4197.7030605@redhat.com \
--to=pbonzini@redhat.com \
--cc=asias@redhat.com \
--cc=gleb@redhat.com \
--cc=nab@linux-iscsi.org \
--cc=pbadari@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).