qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu seabios issue with vhost-scsi


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] qemu seabios issue with vhost-scsi
Date: Thu, 23 May 2013 14:45:28 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, May 22, 2013 at 05:36:08PM -0700, Badari wrote:
> Hi,
> 
> While testing vhost-scsi in the current qemu git, ran into an earlier issue
> with seabios. I had to disable scsi support in seabios to get it working.
> 
> I was hoping this issue got resolved when vhost-scsi support got
> merged into qemu. Is this still being worked on ?
> 
> Thanks,
> Badari
> 
> [root ~]# gdb /root/qemu/x86_64-softmmu/qemu-system-x86_64
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /root/qemu/x86_64-softmmu/qemu-system-x86_64...done.
> (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/window.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 4725)]
> [New Thread 0x7ffff1239700 (LWP 4726)]
> [New Thread 0x7fffeb7ff700 (LWP 4729)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff1239700 (LWP 4726)]
> 0x00005555556b3191 in scsi_device_find (bus=0x5555565abb50, channel=0, id=0,
>     lun=0) at hw/scsi/scsi-bus.c:1744
> 1744        QTAILQ_FOREACH_REVERSE(kid, &bus->qbus.children,
> ChildrenHead, sibling) {
> 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  0x00005555556b3191 in scsi_device_find (bus=0x5555565abb50,
> channel=0, id=
>     0, lun=0) at hw/scsi/scsi-bus.c:1744
> #1  0x00005555557a59f0 in virtio_scsi_device_find (vdev=0x5555565aba38, vq=
>     0x5555565d1150) at /root/qemu/hw/scsi/virtio-scsi.c:56
> #2  virtio_scsi_handle_cmd (vdev=0x5555565aba38, vq=0x5555565d1150)
>     at /root/qemu/hw/scsi/virtio-scsi.c:376

We should never get here with vhost-scsi.  This function is processing
the command virtqueue in QEMU userspace - if vhost is active then we
shouldn't reach this.

AFAICT the s->bus was not initialized in the vhost codepath.  Therefore
the crash in scsi_device_find(bus, ...).

Can you check vhost_scsi_set_status() was called and if it successfully
enabled vhost?

Is it possible that the guest is notifying the virtqueue before setting
the status register to DRIVER_OK?  That would explain why vhost hasn't
been activated yet.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]