[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH WIP 0/4] vhost-scsi: new device supporting the t
|
From: |
Nicholas A. Bellinger |
|
Subject: |
Re: [Qemu-devel] [PATCH WIP 0/4] vhost-scsi: new device supporting the tcm_vhost Linux kernel module |
|
Date: |
Mon, 04 Feb 2013 12:33:33 -0800 |
Hi Paolo,
On Thu, 2013-01-31 at 00:12 -0800, Nicholas A. Bellinger wrote:
> Hi Paolo,
>
> On Wed, 2013-01-30 at 17:41 +0100, Paolo Bonzini wrote:
<SNIP>
> > As expected, using a separate device finds a snag: vhost-scsi is passing
> > force=false to vhost_dev_init, and the BIOS does not use MSI-X so it
> > will actually use the non-vhost implementation which is wrong. I fixed
> > this by passing force=true; I'm not sure what that would break, but I
> > figured "not much" since the BIOS polls and does not rely on interrupts.
> >
> > That makes vhost start, but it still doesn't work for me with a 3.7.2
> > kernel on the host. Even Nick's patches hang the guest as soon as vhost
> > starts, and I get the same behavior with mine.
>
> After bisection this evening, the change that ended up breaking
> vhost-scsi is vhost backend guest notifier masking support patch in
> commit f56a12475.
>
> After adding the two new notifiers in vhost-scsi/virtio-scsi following
> in qemu.git/virtio-scsi-nab code, the tcm_vhost LUN scan is functioning
> again..
>
> > (Of course with my
> > patches the BIOS hangs and you never reach Linux; but try a BIOS without
> > virtio-scsi support, and you'll see Linux hanging in the same way).
> >
> > Here is my configuration:
> >
> > cd /sys/kernel/config/target
> > mkdir -p core/fileio_0/fileio
> > echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> > core/fileio_0/fileio/control
> > echo 1 > core/fileio_0/fileio/enable
> > mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> > cd vhost/naa.600140554cf3a18e/tpgt_0
> > ln -sf ../../../../../core/fileio_0/fileio/ lun/lun_0/virtual_scsi_port
> > echo naa.60014053226f0388 > nexus
> >
> > Nick's patches are run with "-vhost-scsi
> > id=vs,tpgt=0,wwpn=naa.600140554cf3a18e
> > -device virtio-scsi-pci,vhost-scsi=vs". Perhaps I'm doing something wrong.
>
> So after adding the same vhost backend guest notifiers to the new
> VirtIOSCSICommon vhost-scsi code, I'm now hitting an QEMU invalid
> option:
>
> ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 -serial
> file:/tmp/vhost-serial.txt
> -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2
> -vhost-scsi id=vs,tpgt=0,wwpn=naa.600140579ad21088 -device
> virtio-scsi-pci,vhost-scsi=vs
> qemu-system-x86_64: -vhost-scsi: invalid option
>
> Debugging this now..
>
Ok, so after using the correct -vhost-scsi-pci opts with thew new code
(thanks btw :), I'm also running into a SeaBIOS hang at boot:
Starting program: /usr/src/qemu-paolo.git/x86_64-softmmu/qemu-system-x86_64
-enable-kvm -smp 4 -m 2048 -serial file:/tmp/vhost-serial.txt -hda
/usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 -device
vhost-scsi-pci,wwpn=naa.600140579ad21088
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff43a1700 (LWP 13079)]
[New Thread 0x7ffff399f700 (LWP 13080)]
[New Thread 0x7ffff319e700 (LWP 13081)]
[New Thread 0x7ffff299d700 (LWP 13082)]
[New Thread 0x7ffff219c700 (LWP 13083)]
[Thread 0x7ffff43a1700 (LWP 13079) exited]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff5cca8d3 in select () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff5cca8d3 in select () from /lib/libc.so.6
#1 0x00000000005050e5 in os_host_main_loop_wait (nonblocking=<value optimized
out>) at main-loop.c:230
#2 main_loop_wait (nonblocking=<value optimized out>) at main-loop.c:416
#3 0x000000000056a8ec in main_loop (argc=<value optimized out>, argv=<value
optimized out>,
envp=<value optimized out>) at vl.c:1951
#4 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value
optimized out>) at vl.c:4224
(gdb)
and a quick look with strace:
<SNIP>
ioctl(15, KVM_SET_LAPIC, 0x7fffca93f6e0) = 0
ioctl(15, KVM_SET_PIT2 or KVM_SET_VCPU_EVENTS, 0x7fffca93f6e0) = 0
ioctl(15, 0x4080aea2, 0x7fffca93f6e0) = 0
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
ioctl(7, KVM_CHECK_EXTENSION, 0x4c) = 1
ioctl(12, 0xaead, 0) = -1 EINVAL (Invalid argument)
futex(0x1469ce4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xe54e20, 4) = 1
tgkill(13107, 13109, SIGUSR1) = 0
futex(0x1460114, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xe54e20, 4) = 1
tgkill(13107, 13110, SIGUSR1) = 0
futex(0x14613b4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xe54e20, 4) = 1
tgkill(13107, 13111, SIGUSR1) = 0
futex(0x1454e84, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xe54e20, 4) = 1
tgkill(13107, 13112, SIGUSR1) = 0
select(10, [3 4 5 9], [], [], {0, 0}) = 2 (in [3 4], left {0, 0})
read(4, "\2\0\0\0\0\0\0\0", 512) = 8
read(3,
"\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
128) = 128
rt_sigaction(SIGALRM, NULL, {0x52b810, ~[KILL STOP RTMIN RT_1], SA_RESTORER,
0x7f2c559abf60}, 8) = 0
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
read(3, 0x7fffca93fc60, 128) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=20, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=20, revents=POLLOUT}])
writev(20,
[{"\22\0\7\0\3\0\0\6'\0\0\0\37\0\0\0\10\1\4\0\4\0\0\0QEMU\22\0\7\0"..., 116},
{NULL, 0}, {"", 0}], 3) = 116
poll([{fd=20, events=POLLIN}], 1, -1) = 1 ([{fd=20, revents=POLLIN}])
read(20, "\34\0s\0\3\0\0\6'\0\0\0:\235K\31\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 160
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
read(20, 0x1519bb4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
<SNIP>
And the output from tcm_vhost with pr_debug enabled:
[ 2800.058290] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 2800.058295] vhost_scsi_evt_handle_kick: The handling func for event queue.
[ 2800.058299] Guest moved used index from 0 to 61440
[ 2800.058303] vhost_get_vq_desc: head: -14, out: 4294936582 in: 3068919816
[ 2800.092592] Guest moved used index from 0 to 61440
[ 2800.092595] vhost_get_vq_desc: head: -14, out: 4294936582 in: 3068919816
I've not had a chance to debug this further, any ideas where to start
looking to debug this..?
--nab