Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-09 Thread Asias He
On Fri, Jul 05, 2013 at 07:17:59AM -0400, Vadim Rozenfeld wrote:
 Hi Asias,
 
 Windows driver should be able to support as many logical units and targets
 as reported by QEMU. In case of VIRTIO_SCSI_S_BAD_TARGET it will just 
 propagate
 the relevant SRB error code to the port driver.
 In any case, I will try reproducing this problem on my system. 

Thanks, let me know if you have issue to setup the vhost-scsi
environment. In the other mail of this thread, I wrote a howto to setup
up vhost-scsi in RHEL6.

 Best,
 Vadim.
 
 - Original Message -
 From: Asias He as...@redhat.com
 To: Libaiqing libaiq...@huawei.com
 Cc: Paolo Bonzini pbonz...@redhat.com, Wenchao Xia 
 xiaw...@linux.vnet.ibm.com, qemu-devel@nongnu.org, n...@linux-iscsi.org, 
 Michael S. Tsirkin m...@redhat.com, Haofeng haof...@huawei.com, 
 Vadim Rozenfeld vroze...@redhat.com, Yan Vugenfirer 
 yvuge...@redhat.com
 Sent: Friday, July 5, 2013 4:52:05 PM
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the 
 tcm_vhost Linux kernel module
 
 [CCing Vadim and Yan]
 
 On Thu, Jul 04, 2013 at 07:00:49AM +, Libaiqing wrote:
  Hi asias,
  1 Window can not boot from vhost-scsi device;
  2 A non-bootable vhost-scsi device can not be driven by windows 
  guest.(I used the driver virtio-win-0.1-59 version.)
  
  Do you have any plan about these?
 
 I can reproduce this issue on win2003 (Linux guest works fine). The guest
 hangs in the boot process. OS is on virito-blk disk, vhost-scsi is
 attached as the second disk.
 
 Guest probes from target 0 to 255. Only target 1 is available.
 vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except
 tareget 1. Howerver, from the log we can see, guest is sending to target
 0 again and hangs afterwards.
 
 Vadim and Yan, any ideas?
 
 [ 3109.954237] br0: port 2(tap0) entered disabled state
 [ 3109.954387] device tap0 left promiscuous mode
 [ 3109.954389] br0: port 2(tap0) entered disabled state
 [ 3119.534136] device tap0 entered promiscuous mode
 [ 3119.534169] br0: port 2(tap0) entered forwarding state
 [ 3119.534180] br0: port 2(tap0) entered forwarding state
 [ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control 
 queue.
 [ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2
 [ 3120.138669] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006c15, len: 51
 [ 3120.138671] target=0, tpg=  (null)
 [ 3120.138672] send bad target head=0, out=1
 [ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2
 [ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2
 [ 3120.139221] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006c15, len: 51
 [ 3120.139223] target=1, tpg=88021f8fc800
 [ 3120.139225] Allocated tv_cmd: 880223cbf800 exp_data_len: 36, 
 data_direction: 2
 [ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0
 [ 3120.139228] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 
 is_err 0
 [ 3120.139229] Mapping 1 iovecs for 1 pages
 [ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2
 [ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
 status 0x0
 [ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1
 [ 3120.139472] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006bd9, len: 51
 [ 3120.139474] target=1, tpg=88021f8fc800
 [ 3120.139475] Allocated tv_cmd: 880223cbf800 exp_data_len: 0, 
 data_direction: 3
 [ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0
 [ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1
 [ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
 status 0x0
 [ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2
 [ 3120.139557] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006c15, len: 51
 [ 3120.139558] target=1, tpg=88021f8fc800
 [ 3120.139560] Allocated tv_cmd: 880223cbf800 exp_data_len: 8, 
 data_direction: 2
 [ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0
 [ 3120.139563] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 
 is_err 0
 [ 3120.139564] Mapping 1 iovecs for 1 pages
 [ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2
 [ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
 status 0x0
 [ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2
 [ 3120.139785] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006c15, len: 51
 [ 3120.139787] target=2, tpg=  (null)
 [ 3120.139788] send bad target head=0, out=1
 [ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2
 [ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2
 [ 3120.139940] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006c15, len: 51
 
 ...
 
 [ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2
 [ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2
 [ 3120.170305] Calling __copy_from_user: vq-iov[0].iov_base: 
 7f8f28006c15, len: 51
 [ 3120.170306] target=255, tpg=  (null)
 [ 3120.170306

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-07 Thread Libaiqing
Hi paolo,
   Sorry for the late reply.
   LVM partition is in guest.So when booting for vhost-scsi,the guest always 
reports the fs is broken,and enters the emergency mode.
   
   I can provide more information if need.

Thanks
Baiqing.
 -Original Message-
 From: Paolo Bonzini [mailto:pbonz...@redhat.com]
 Sent: Thursday, July 04, 2013 7:24 PM
 To: Libaiqing
 Cc: Asias He; Wenchao Xia; qemu-devel@nongnu.org; n...@linux-iscsi.org;
 Michael S. Tsirkin; Haofeng
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
 tcm_vhost Linux kernel module
 
 Il 03/07/2013 14:33, Libaiqing ha scritto:
  Hi asias,
  I got the rootcause:guest was installed on raw img with lvm
 partition,which vhost does not support.
 
 You mean LVM in the host or the guest?  I guess in the host, but I'd
 rather make sure because otherwise you've found a bug.
 
 Paolo
 
  Now vhost-scsi can be used as bootable device.




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-05 Thread Asias He
 iovecs for 1 pages
[ 3120.532857] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.532863] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.532889] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.532891] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f280efe85, 
len: 51
[ 3120.532892] target=1, tpg=88021f8fc800
[ 3120.532894] Allocated tv_cmd: 880223cbf800 exp_data_len: 512, 
data_direction: 2
[ 3120.532895] vhost_scsi got command opcode: 0x28, lun: 0
[ 3120.532897] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0
[ 3120.532898] Mapping 1 iovecs for 1 pages
[ 3120.532901] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.532906] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3123.852940] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3123.853694] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3123.853696] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f2e6c53ac, 
len: 51
[ 3123.853697] target=0, tpg=  (null)
[ 3123.853698] send bad target head=0, out=1
[ 3123.853700] vhost_get_vq_desc: head: 128, out: 1 in: 2

 Thanks,
 Baiqing.
  -Original Message-
  From: Asias He [mailto:as...@redhat.com]
  Sent: Wednesday, July 03, 2013 4:09 PM
  To: Libaiqing
  Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
  n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
  Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
  tcm_vhost Linux kernel module
  
  On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
   On Fri, Jun 21, 2013 at 10:16:48AM +, Libaiqing wrote:
Hi Asias,
   
 -Original Message-
 From: Asias He [mailto:as...@redhat.com]
 Sent: Thursday, June 20, 2013 5:39 PM
 To: Libaiqing
 Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
 n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
  supporting the
 tcm_vhost Linux kernel module

 On Thu, Jun 20, 2013 at 08:49:50AM +, Libaiqing wrote:
  Hi Asias,
  Thanks for your config.
  According to you config,I test booting from vhost device with
 upstream kernel and qemu,but failed.
 
  1 installing guest from cdrom,ok.
  2 booting vhost-scsi,guest fs error occurs.
  3 using fileio backstores,the error is same..
  4 rebooting guest,a log printed:
   (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
  Object
 0x7fccae7f2c88 is not an instance of type virtio-scsi-device

 Paolo, I remember you fixed a similar issue?

  5 using upstream seabios,core dumped.
 
  Could you give me some advise to debug this problem ? I can
  provide
 more information if need.

 Can you show me qemu commit id you used? Can you verity that if
  using the
 host kernel for guest helps? Does booting directly (without the 
 install
 and reboot process) work?
Qemu commit id is commit
  4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
   
Guest kernel updateing is useless.
   
Booting directly doesn't work too.
  
  
   Hello Libaiqing,
  
   Sorry for the delay. I will try to reproduce it myself.
  
  I tried 1.5.1 and qemu.git/master and your particular commit
  4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
  
  All work well for me. I used 3.10.0-rc6 as both and guest kernel.
  
  
   
  The qemu cmd:
  [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
  -enable-kvm
 -name fedora   -M pc -m 1024 -smp 2   -drive
 file=/home/fedora18.iso,if=ide,media=cdrom -device
 vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga
  qxl
 -vnc :1
 
  The vnc output:
  Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
 INCONSISTENCY;RUN FSCK MANUALLY.
  Dracut-initqueue[189]: Warning: e2fsck returned with 4
  Dracut-initqueue[189]: Warning: ***An error occurred during the file
 system check.
 
  The guest kernel log:
  Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
  Kernel: scsi2 : Virtio SCSI HBA
  Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
  Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
  Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
  Kernel: sd 2:0:1:0: [sda]write protect is off
  Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
  Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
  Kernel: sda sda1 sda2
  Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
  Dracut-initqueue[189]: Scanning devices sda2 for LVM
  Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
  Dracut-initqueue[189]: inactive '/dev/fedora/root'...
 
  The info of host

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-05 Thread Vadim Rozenfeld
Hi Asias,

Windows driver should be able to support as many logical units and targets
as reported by QEMU. In case of VIRTIO_SCSI_S_BAD_TARGET it will just propagate
the relevant SRB error code to the port driver.
In any case, I will try reproducing this problem on my system. 

Best,
Vadim.

- Original Message -
From: Asias He as...@redhat.com
To: Libaiqing libaiq...@huawei.com
Cc: Paolo Bonzini pbonz...@redhat.com, Wenchao Xia 
xiaw...@linux.vnet.ibm.com, qemu-devel@nongnu.org, n...@linux-iscsi.org, 
Michael S. Tsirkin m...@redhat.com, Haofeng haof...@huawei.com, Vadim 
Rozenfeld vroze...@redhat.com, Yan Vugenfirer yvuge...@redhat.com
Sent: Friday, July 5, 2013 4:52:05 PM
Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the 
tcm_vhost Linux kernel module

[CCing Vadim and Yan]

On Thu, Jul 04, 2013 at 07:00:49AM +, Libaiqing wrote:
 Hi asias,
 1 Window can not boot from vhost-scsi device;
 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I 
 used the driver virtio-win-0.1-59 version.)
 
 Do you have any plan about these?

I can reproduce this issue on win2003 (Linux guest works fine). The guest
hangs in the boot process. OS is on virito-blk disk, vhost-scsi is
attached as the second disk.

Guest probes from target 0 to 255. Only target 1 is available.
vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except
tareget 1. Howerver, from the log we can see, guest is sending to target
0 again and hangs afterwards.

Vadim and Yan, any ideas?

[ 3109.954237] br0: port 2(tap0) entered disabled state
[ 3109.954387] device tap0 left promiscuous mode
[ 3109.954389] br0: port 2(tap0) entered disabled state
[ 3119.534136] device tap0 entered promiscuous mode
[ 3119.534169] br0: port 2(tap0) entered forwarding state
[ 3119.534180] br0: port 2(tap0) entered forwarding state
[ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.138669] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.138671] target=0, tpg=  (null)
[ 3120.138672] send bad target head=0, out=1
[ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139221] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.139223] target=1, tpg=88021f8fc800
[ 3120.139225] Allocated tv_cmd: 880223cbf800 exp_data_len: 36, 
data_direction: 2
[ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0
[ 3120.139228] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0
[ 3120.139229] Mapping 1 iovecs for 1 pages
[ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1
[ 3120.139472] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006bd9, 
len: 51
[ 3120.139474] target=1, tpg=88021f8fc800
[ 3120.139475] Allocated tv_cmd: 880223cbf800 exp_data_len: 0, 
data_direction: 3
[ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0
[ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1
[ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139557] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.139558] target=1, tpg=88021f8fc800
[ 3120.139560] Allocated tv_cmd: 880223cbf800 exp_data_len: 8, 
data_direction: 2
[ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0
[ 3120.139563] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0
[ 3120.139564] Mapping 1 iovecs for 1 pages
[ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139785] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.139787] target=2, tpg=  (null)
[ 3120.139788] send bad target head=0, out=1
[ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139940] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, 
len: 51

...

[ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.170305] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.170306] target=255, tpg=  (null)
[ 3120.170306] send bad target head=0, out=1
[ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.474652] Calling __copy_from_user: vq-iov[0].iov_base: 7f8f280efe85, 
len: 51
[ 3120.474654] target=1, tpg=88021f8fc800
[ 3120.474656] Allocated tv_cmd: 880223cbf800 exp_data_len

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-04 Thread Paolo Bonzini
Il 03/07/2013 14:33, Libaiqing ha scritto:
 Hi asias,
 I got the rootcause:guest was installed on raw img with lvm 
 partition,which vhost does not support.

You mean LVM in the host or the guest?  I guess in the host, but I'd
rather make sure because otherwise you've found a bug.

Paolo

 Now vhost-scsi can be used as bootable device.




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-04 Thread Asias He
On Thu, Jul 04, 2013 at 07:00:49AM +, Libaiqing wrote:
 Hi asias,
 1 Window can not boot from vhost-scsi device;
 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I 
 used the driver virtio-win-0.1-59 version.)
 
 Do you have any plan about these?

Thanks for testing. I will take a look.

 
 Thanks,
 Baiqing.
  -Original Message-
  From: Asias He [mailto:as...@redhat.com]
  Sent: Wednesday, July 03, 2013 4:09 PM
  To: Libaiqing
  Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
  n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
  Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
  tcm_vhost Linux kernel module
  
  On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
   On Fri, Jun 21, 2013 at 10:16:48AM +, Libaiqing wrote:
Hi Asias,
   
 -Original Message-
 From: Asias He [mailto:as...@redhat.com]
 Sent: Thursday, June 20, 2013 5:39 PM
 To: Libaiqing
 Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
 n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
  supporting the
 tcm_vhost Linux kernel module

 On Thu, Jun 20, 2013 at 08:49:50AM +, Libaiqing wrote:
  Hi Asias,
  Thanks for your config.
  According to you config,I test booting from vhost device with
 upstream kernel and qemu,but failed.
 
  1 installing guest from cdrom,ok.
  2 booting vhost-scsi,guest fs error occurs.
  3 using fileio backstores,the error is same..
  4 rebooting guest,a log printed:
   (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
  Object
 0x7fccae7f2c88 is not an instance of type virtio-scsi-device

 Paolo, I remember you fixed a similar issue?

  5 using upstream seabios,core dumped.
 
  Could you give me some advise to debug this problem ? I can
  provide
 more information if need.

 Can you show me qemu commit id you used? Can you verity that if
  using the
 host kernel for guest helps? Does booting directly (without the 
 install
 and reboot process) work?
Qemu commit id is commit
  4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
   
Guest kernel updateing is useless.
   
Booting directly doesn't work too.
  
  
   Hello Libaiqing,
  
   Sorry for the delay. I will try to reproduce it myself.
  
  I tried 1.5.1 and qemu.git/master and your particular commit
  4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
  
  All work well for me. I used 3.10.0-rc6 as both and guest kernel.
  
  
   
  The qemu cmd:
  [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
  -enable-kvm
 -name fedora   -M pc -m 1024 -smp 2   -drive
 file=/home/fedora18.iso,if=ide,media=cdrom -device
 vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga
  qxl
 -vnc :1
 
  The vnc output:
  Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
 INCONSISTENCY;RUN FSCK MANUALLY.
  Dracut-initqueue[189]: Warning: e2fsck returned with 4
  Dracut-initqueue[189]: Warning: ***An error occurred during the file
 system check.
 
  The guest kernel log:
  Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
  Kernel: scsi2 : Virtio SCSI HBA
  Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
  Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
  Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
  Kernel: sd 2:0:1:0: [sda]write protect is off
  Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
  Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
  Kernel: sda sda1 sda2
  Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
  Dracut-initqueue[189]: Scanning devices sda2 for LVM
  Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
  Dracut-initqueue[189]: inactive '/dev/fedora/root'...
 
  The info of host:
  [root@fedora121 x86_64-softmmu]# uname -a
  Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
  x86_64
 x86_64 x86_64 GNU/Linux
  [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
  vhost_scsi 49456  5
  target_core_mod   282163  14

  target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
 ost_scsi
  [root@fedora121 x86_64-softmmu]# targetcli
  targetcli shell version v2.1.fb26
  Copyright 2011 by RisingTide Systems LLC and others.
  For help on commands, type 'help'.
 
  / ls
  o-

  / 
  ..
 ... [...]
o-

  backstores

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-03 Thread Asias He
On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
 On Fri, Jun 21, 2013 at 10:16:48AM +, Libaiqing wrote:
  Hi Asias,
  
   -Original Message-
   From: Asias He [mailto:as...@redhat.com]
   Sent: Thursday, June 20, 2013 5:39 PM
   To: Libaiqing
   Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
   n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
   Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting 
   the
   tcm_vhost Linux kernel module
   
   On Thu, Jun 20, 2013 at 08:49:50AM +, Libaiqing wrote:
Hi Asias,
Thanks for your config.
According to you config,I test booting from vhost device with
   upstream kernel and qemu,but failed.
   
1 installing guest from cdrom,ok.
2 booting vhost-scsi,guest fs error occurs.
3 using fileio backstores,the error is same..
4 rebooting guest,a log printed:
 (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object
   0x7fccae7f2c88 is not an instance of type virtio-scsi-device
   
   Paolo, I remember you fixed a similar issue?
   
5 using upstream seabios,core dumped.
   
Could you give me some advise to debug this problem ? I can provide
   more information if need.
   
   Can you show me qemu commit id you used? Can you verity that if using the
   host kernel for guest helps? Does booting directly (without the install
   and reboot process) work?
  Qemu commit id is commit 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
  
  Guest kernel updateing is useless.
  
  Booting directly doesn't work too.
 
 
 Hello Libaiqing,
 
 Sorry for the delay. I will try to reproduce it myself.

I tried 1.5.1 and qemu.git/master and your particular commit
4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.

All work well for me. I used 3.10.0-rc6 as both and guest kernel.

 
  
The qemu cmd:
[root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm
   -name fedora   -M pc -m 1024 -smp 2   -drive
   file=/home/fedora18.iso,if=ide,media=cdrom -device
   vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga qxl
   -vnc :1
   
The vnc output:
Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
   INCONSISTENCY;RUN FSCK MANUALLY.
Dracut-initqueue[189]: Warning: e2fsck returned with 4
Dracut-initqueue[189]: Warning: ***An error occurred during the file
   system check.
   
The guest kernel log:
Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
Kernel: scsi2 : Virtio SCSI HBA
Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
Kernel: sd 2:0:1:0: [sda]write protect is off
Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
Kernel: sda sda1 sda2
Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
Dracut-initqueue[189]: Scanning devices sda2 for LVM
Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
Dracut-initqueue[189]: inactive '/dev/fedora/root'...
   
The info of host:
[root@fedora121 x86_64-softmmu]# uname -a
Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64
   x86_64 x86_64 GNU/Linux
[root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
vhost_scsi 49456  5
target_core_mod   282163  14
   target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
   ost_scsi
[root@fedora121 x86_64-softmmu]# targetcli
targetcli shell version v2.1.fb26
Copyright 2011 by RisingTide Systems LLC and others.
For help on commands, type 'help'.
   
/ ls
o-
   / 
   ..
   ... [...]
  o-
   backstores 
   ...
   ... [...]
  | o-
   block 
   ..
   [Storage Objects: 0]
  | o-
   fileio 
   .
   [Storage Objects: 0]
  | o-
   pscsi 
   ..
   [Storage Objects: 0]
  | o-
   ramdisk 
   
   [Storage Objects: 1]
  |   o-
   r0 
   ...
   [(6.0GiB) activated]
  o-
   iscsi

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-03 Thread Libaiqing
Hi asias,
I got the rootcause:guest was installed on raw img with lvm partition,which 
vhost does not support.

Now vhost-scsi can be used as bootable device.
Thanks
baiqing
 -Original Message-
 From: Asias He [mailto:as...@redhat.com]
 Sent: Wednesday, July 03, 2013 4:09 PM
 To: Libaiqing
 Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
 n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
 tcm_vhost Linux kernel module
 
 On Wed, Jul 03, 2013 at 11:23:26AM +0800, Asias He wrote:
  On Fri, Jun 21, 2013 at 10:16:48AM +, Libaiqing wrote:
   Hi Asias,
  
-Original Message-
From: Asias He [mailto:as...@redhat.com]
Sent: Thursday, June 20, 2013 5:39 PM
To: Libaiqing
Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device
 supporting the
tcm_vhost Linux kernel module
   
On Thu, Jun 20, 2013 at 08:49:50AM +, Libaiqing wrote:
 Hi Asias,
 Thanks for your config.
 According to you config,I test booting from vhost device with
upstream kernel and qemu,but failed.

 1 installing guest from cdrom,ok.
 2 booting vhost-scsi,guest fs error occurs.
 3 using fileio backstores,the error is same..
 4 rebooting guest,a log printed:
  (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event:
 Object
0x7fccae7f2c88 is not an instance of type virtio-scsi-device
   
Paolo, I remember you fixed a similar issue?
   
 5 using upstream seabios,core dumped.

 Could you give me some advise to debug this problem ? I can
 provide
more information if need.
   
Can you show me qemu commit id you used? Can you verity that if
 using the
host kernel for guest helps? Does booting directly (without the install
and reboot process) work?
   Qemu commit id is commit
 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
  
   Guest kernel updateing is useless.
  
   Booting directly doesn't work too.
 
 
  Hello Libaiqing,
 
  Sorry for the delay. I will try to reproduce it myself.
 
 I tried 1.5.1 and qemu.git/master and your particular commit
 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
 
 All work well for me. I used 3.10.0-rc6 as both and guest kernel.
 
 
  
 The qemu cmd:
 [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64
 -enable-kvm
-name fedora   -M pc -m 1024 -smp 2   -drive
file=/home/fedora18.iso,if=ide,media=cdrom -device
vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga
 qxl
-vnc :1

 The vnc output:
 Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
INCONSISTENCY;RUN FSCK MANUALLY.
 Dracut-initqueue[189]: Warning: e2fsck returned with 4
 Dracut-initqueue[189]: Warning: ***An error occurred during the file
system check.

 The guest kernel log:
 Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
 Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
 Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
 Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
 Kernel: scsi2 : Virtio SCSI HBA
 Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
 Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
 Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
 Kernel: sd 2:0:1:0: [sda]write protect is off
 Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
 Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
 Kernel: sda sda1 sda2
 Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
 Dracut-initqueue[189]: Scanning devices sda2 for LVM
 Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
 Dracut-initqueue[189]: inactive '/dev/fedora/root'...

 The info of host:
 [root@fedora121 x86_64-softmmu]# uname -a
 Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013
 x86_64
x86_64 x86_64 GNU/Linux
 [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
 vhost_scsi 49456  5
 target_core_mod   282163  14
   
 target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
ost_scsi
 [root@fedora121 x86_64-softmmu]# targetcli
 targetcli shell version v2.1.fb26
 Copyright 2011 by RisingTide Systems LLC and others.
 For help on commands, type 'help'.

 / ls
 o-
   
 / 
 ..
... [...]
   o-
   
 backstores 
 ...
... [...]
   | o-
   
 block 
 ..
[Storage Objects: 0]
   | o-
   
 fileio

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-02 Thread Asias He
On Wed, Jul 03, 2013 at 03:08:34AM +, Libaiqing wrote:
 Hi asias,
I'm testing vhost-blk,for comparimg the performance with virtio-blk.
I got the kernel patch from this mail: https://lkml.org/lkml/2012/12/1/174

You can find the latest vhost-blk kernel bits here:

  git://github.com/asias/linux.git blk.vhost-blk

And I got the userspace code for qemu from this git: 
 https://github.com/asias/qemu/tree/blk.vhost-blk;
Used vhost-blk device as non-bootable device,the configuration is :   
 Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c 
 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
 file=/home/fedora188.img,if=virtio,index=0,format=raw  -drive 
 file=/home/fedora18.img,if=virtio,index=1,format=raw,id=hd,vhost=on   
 -monitor stdio   -vga qxl  -vnc :1  -device usb-tablet,id=input0

Please use raw block device for vhost-blk.

On fedora17 host,I used kernel 3.6.3 for building vhos_blk module,but the 
 vm will hang when vm starting.
 
1 Is there any new patch for kernel 3.8 3.10?
2 which version of the kernel is suitable for the current kernel patch?
 
Could you give me some advise to debug this problem ? I can provide more 
 information if need.
Or could you give me some advise to run vhost-blk,such as RHEL 
 version,kernel version and so on?

I recommend you to use the kernel I provided above for both guest and
host.

 Thanks
 Baiqing. 

-- 
Asias



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-07-02 Thread Asias He
On Fri, Jun 21, 2013 at 10:16:48AM +, Libaiqing wrote:
 Hi Asias,
 
  -Original Message-
  From: Asias He [mailto:as...@redhat.com]
  Sent: Thursday, June 20, 2013 5:39 PM
  To: Libaiqing
  Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
  n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
  Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
  tcm_vhost Linux kernel module
  
  On Thu, Jun 20, 2013 at 08:49:50AM +, Libaiqing wrote:
   Hi Asias,
   Thanks for your config.
   According to you config,I test booting from vhost device with
  upstream kernel and qemu,but failed.
  
   1 installing guest from cdrom,ok.
   2 booting vhost-scsi,guest fs error occurs.
   3 using fileio backstores,the error is same..
   4 rebooting guest,a log printed:
(qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object
  0x7fccae7f2c88 is not an instance of type virtio-scsi-device
  
  Paolo, I remember you fixed a similar issue?
  
   5 using upstream seabios,core dumped.
  
   Could you give me some advise to debug this problem ? I can provide
  more information if need.
  
  Can you show me qemu commit id you used? Can you verity that if using the
  host kernel for guest helps? Does booting directly (without the install
  and reboot process) work?
 Qemu commit id is commit 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.
 
 Guest kernel updateing is useless.
 
 Booting directly doesn't work too.


Hello Libaiqing,

Sorry for the delay. I will try to reproduce it myself.

 
   The qemu cmd:
   [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm
  -name fedora   -M pc -m 1024 -smp 2   -drive
  file=/home/fedora18.iso,if=ide,media=cdrom -device
  vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga qxl
  -vnc :1
  
   The vnc output:
   Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
  INCONSISTENCY;RUN FSCK MANUALLY.
   Dracut-initqueue[189]: Warning: e2fsck returned with 4
   Dracut-initqueue[189]: Warning: ***An error occurred during the file
  system check.
  
   The guest kernel log:
   Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
   Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
   Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
   Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
   Kernel: scsi2 : Virtio SCSI HBA
   Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
   Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
   Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
   Kernel: sd 2:0:1:0: [sda]write protect is off
   Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
   Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
   Kernel: sda sda1 sda2
   Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
   Dracut-initqueue[189]: Scanning devices sda2 for LVM
   Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
   Dracut-initqueue[189]: inactive '/dev/fedora/root'...
  
   The info of host:
   [root@fedora121 x86_64-softmmu]# uname -a
   Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64
  x86_64 x86_64 GNU/Linux
   [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
   vhost_scsi 49456  5
   target_core_mod   282163  14
  target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
  ost_scsi
   [root@fedora121 x86_64-softmmu]# targetcli
   targetcli shell version v2.1.fb26
   Copyright 2011 by RisingTide Systems LLC and others.
   For help on commands, type 'help'.
  
   / ls
   o-
  / 
  ..
  ... [...]
 o-
  backstores 
  ...
  ... [...]
 | o-
  block 
  ..
  [Storage Objects: 0]
 | o-
  fileio 
  .
  [Storage Objects: 0]
 | o-
  pscsi 
  ..
  [Storage Objects: 0]
 | o-
  ramdisk 
  
  [Storage Objects: 1]
 |   o-
  r0 
  ...
  [(6.0GiB) activated]
 o-
  iscsi 
  .
  ... [Targets: 0]
 o-
  loopback 
  ..
  ... [Targets: 0]
 o-
  vhost 
  ...
  . [Targets: 1]
   o-
  naa

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-06-21 Thread Libaiqing
Hi Asias,

 -Original Message-
 From: Asias He [mailto:as...@redhat.com]
 Sent: Thursday, June 20, 2013 5:39 PM
 To: Libaiqing
 Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
 n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
 tcm_vhost Linux kernel module
 
 On Thu, Jun 20, 2013 at 08:49:50AM +, Libaiqing wrote:
  Hi Asias,
  Thanks for your config.
  According to you config,I test booting from vhost device with
 upstream kernel and qemu,but failed.
 
  1 installing guest from cdrom,ok.
  2 booting vhost-scsi,guest fs error occurs.
  3 using fileio backstores,the error is same..
  4 rebooting guest,a log printed:
   (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object
 0x7fccae7f2c88 is not an instance of type virtio-scsi-device
 
 Paolo, I remember you fixed a similar issue?
 
  5 using upstream seabios,core dumped.
 
  Could you give me some advise to debug this problem ? I can provide
 more information if need.
 
 Can you show me qemu commit id you used? Can you verity that if using the
 host kernel for guest helps? Does booting directly (without the install
 and reboot process) work?
Qemu commit id is commit 4eda32f588086b6cd0ec2be6a7a6c131f8c2b427.

Guest kernel updateing is useless.

Booting directly doesn't work too.


  The qemu cmd:
  [root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm
 -name fedora   -M pc -m 1024 -smp 2   -drive
 file=/home/fedora18.iso,if=ide,media=cdrom -device
 vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga qxl
 -vnc :1
 
  The vnc output:
  Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED
 INCONSISTENCY;RUN FSCK MANUALLY.
  Dracut-initqueue[189]: Warning: e2fsck returned with 4
  Dracut-initqueue[189]: Warning: ***An error occurred during the file
 system check.
 
  The guest kernel log:
  Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
  Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
  Kernel: scsi2 : Virtio SCSI HBA
  Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
  Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
  Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
  Kernel: sd 2:0:1:0: [sda]write protect is off
  Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
  Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
  Kernel: sda sda1 sda2
  Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
  Dracut-initqueue[189]: Scanning devices sda2 for LVM
  Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
  Dracut-initqueue[189]: inactive '/dev/fedora/root'...
 
  The info of host:
  [root@fedora121 x86_64-softmmu]# uname -a
  Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64
 x86_64 x86_64 GNU/Linux
  [root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
  vhost_scsi 49456  5
  target_core_mod   282163  14
 target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vh
 ost_scsi
  [root@fedora121 x86_64-softmmu]# targetcli
  targetcli shell version v2.1.fb26
  Copyright 2011 by RisingTide Systems LLC and others.
  For help on commands, type 'help'.
 
  / ls
  o-
 / 
 ..
 ... [...]
o-
 backstores 
 ...
 ... [...]
| o-
 block 
 ..
 [Storage Objects: 0]
| o-
 fileio 
 .
 [Storage Objects: 0]
| o-
 pscsi 
 ..
 [Storage Objects: 0]
| o-
 ramdisk 
 
 [Storage Objects: 1]
|   o-
 r0 
 ...
 [(6.0GiB) activated]
o-
 iscsi 
 .
 ... [Targets: 0]
o-
 loopback 
 ..
 ... [Targets: 0]
o-
 vhost 
 ...
 . [Targets: 1]
  o-
 naa.50014057133e25dc 
 
 .. [TPGs: 1]
o-
 tpg1 
 ...
 [naa.5001405a70ac3421]
  o

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-06-20 Thread Libaiqing
Hi Asias,
Thanks for your config.
According to you config,I test booting from vhost device with upstream 
kernel and qemu,but failed.

1 installing guest from cdrom,ok.
2 booting vhost-scsi,guest fs error occurs. 
3 using fileio backstores,the error is same..
4 rebooting guest,a log printed:
 (qemu) hw/scsi/virtio-scsi.c:533:virtio_scsi_handle_event: Object 
0x7fccae7f2c88 is not an instance of type virtio-scsi-device
5 using upstream seabios,core dumped.
 
Could you give me some advise to debug this problem ? I can provide more 
information if need.

The qemu cmd:
[root@fedora121 x86_64-softmmu]# ./qemu-system-x86_64 -enable-kvm -name fedora  
 -M pc -m 1024 -smp 2   -drive file=/home/fedora18.iso,if=ide,media=cdrom 
-device vhost-scsi-pci,wwpn=naa.50014057133e25dc  -monitor stdio   -vga qxl  
-vnc :1

The vnc output:
Dracut-initqueue[189]:/dev/mapper/fedora-root:UNEXPECTED INCONSISTENCY;RUN FSCK 
MANUALLY.
Dracut-initqueue[189]: Warning: e2fsck returned with 4
Dracut-initqueue[189]: Warning: ***An error occurred during the file system 
check.

The guest kernel log:
Kernel: virtio-pci :00:04.0: irq 40 for MSI/MSI-X
Kernel: virtio-pci :00:04.0: irq 41 for MSI/MSI-X
Kernel: virtio-pci :00:04.0: irq 42 for MSI/MSI-X
Kernel: virtio-pci :00:04.0: irq 43 for MSI/MSI-X
Kernel: scsi2 : Virtio SCSI HBA
Kernel: scsi 2:0:1:0: Direct-Access LIO-ORG r0
Kernel: sd 2:0:1:0: Attached scsi generic sg1 type 0
Kernel: sd 2:0:1:0: [sda]1258912 512-byte logical .
Kernel: sd 2:0:1:0: [sda]write protect is off
Kernel: sd 2:0:1:0: [sda]Mode sense :43 00 00 08
Kernel: sd 2:0:1:0: [sda]write cache: disabled, read .
Kernel: sda sda1 sda2
Kernel: sd 2:0:1:0: [sda] Attached SCSI disk
Dracut-initqueue[189]: Scanning devices sda2 for LVM
Dracut-initqueue[189]: inactive '/dev/fedora/swap'...
Dracut-initqueue[189]: inactive '/dev/fedora/root'...

The info of host:
[root@fedora121 x86_64-softmmu]# uname -a
Linux fedora121 3.10.0-rc6 #1 SMP Wed Jun 19 19:34:24 CST 2013 x86_64 x86_64 
x86_64 GNU/Linux
[root@fedora121 x86_64-softmmu]# lsmod |grep vhost_scsi
vhost_scsi 49456  5
target_core_mod   282163  14 
target_core_iblock,target_core_pscsi,iscsi_target_mod,target_core_file,vhost_scsi
[root@fedora121 x86_64-softmmu]# targetcli
targetcli shell version v2.1.fb26
Copyright 2011 by RisingTide Systems LLC and others.
For help on commands, type 'help'.

/ ls
o- / 
.
 [...]
  o- backstores 
..
 [...]
  | o- block 
..
 [Storage Objects: 0]
  | o- fileio 
.
 [Storage Objects: 0]
  | o- pscsi 
..
 [Storage Objects: 0]
  | o- ramdisk 

 [Storage Objects: 1]
  |   o- r0 
...
 [(6.0GiB) activated]
  o- iscsi 

 [Targets: 0]
  o- loopback 
.
 [Targets: 0]
  o- vhost 

 [Targets: 1]
o- naa.50014057133e25dc 
..
 [TPGs: 1]
  o- tpg1 
...
 [naa.5001405a70ac3421]
o- acls 
..
 [ACLs: 0]
o- luns 
..
 [LUNs: 1]
  o- lun0 
.
 [ramdisk/r0]

Regards,
baiqing
 -Original Message-
 From: Asias He [mailto:as...@redhat.com]
 Sent: Thursday, June 20, 2013 9:34 AM
 To: Libaiqing
 Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
 n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
 tcm_vhost Linux kernel module
 
 On Wed, Jun 19, 2013 at 12:55:10PM +, Libaiqing wrote:
  Hi paolo,
The vhost-scsi device can be used as boot device?
I tested with your config + 3.10 rc6

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-06-20 Thread Asias He
  Cc: Paolo Bonzini; Wenchao Xia; qemu-devel@nongnu.org;
  n...@linux-iscsi.org; Michael S. Tsirkin; Haofeng
  Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
  tcm_vhost Linux kernel module
  
  On Wed, Jun 19, 2013 at 12:55:10PM +, Libaiqing wrote:
   Hi paolo,
 The vhost-scsi device can be used as boot device?
 I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
 Could you give me some advise to debug this problem ? I can provide
  more information if need.
  
  Boot from vhost-scsi is supposed to work. The seabios you used should be
  fine which contains the fixes for vhost-scsi.
  
  Instead of playing with the /sys/kernel/config/target directly, I really
  recommend using targetcli utils.
  
  Nab, I think we really should write some docs for people to use
  vhost-scsi.
  
  This is how I install and use targetcli in RHEL6. Note you need upstream
  kernel and qemu bits for vhost-scsi.
  
  # yum groupinstall  'Development tools'
  # yum install python-devel epydoc python-simpleparse
  
  # git clone git://github.com/agrover/rtslib-fb.git
  # git clone git://github.com/agrover/targetcli-fb.git
  # git clone git://github.com/agrover/configshell-fb.git
  # for i in rtslib-fb configshell-fb targetcli-fb; do
  make -C $i rpm
  yum localinstall $i/dist/*.noarch.rpm
done
  
  In targetcli, create a backstore and vhost wwpn, e.g.
  # targetcli
  / /backstores/ramdisk create r0 1g
  / /vhost create
  / cd /vhost/naa.500140527cb6616b/tpg1/luns
  / create /backstores/ramdisk/r0
  
  # qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...
  
  Hope this helps.
  
   Regards,
   baiqing
  
-Original Message-
From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
[mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On
Behalf Of Paolo Bonzini
Sent: Tuesday, May 28, 2013 4:01 PM
To: Wenchao Xia
Cc: as...@redhat.com; qemu-devel@nongnu.org; n...@linux-iscsi.org;
Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting
  the
tcm_vhost Linux kernel module
   
Il 28/05/2013 09:13, Wenchao Xia ha scritto:
  From: Nicholas Bellinger n...@linux-iscsi.org
 
  The WWPN specified in configfs is passed to -device
  vhost-scsi-pci.
  The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is 
  not
  available from the QEMU command-line.  Instead, I hardcode it to
zero.
 
 Hi, Paolo
   Any document about how to config it correctly in configfs, before
 invoking qemu with the WWPN number?
   
Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:
   
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
   
The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
target WWN that you have to pass to -device vhost-scsi-pci.
   
Paolo
  
  
  --
  Asias

-- 
Asias



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-06-19 Thread Libaiqing
Hi paolo,
  The vhost-scsi device can be used as boot device?
  I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
  Could you give me some advise to debug this problem ? I can provide more 
information if need.

Regards,
baiqing

 -Original Message-
 From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
 [mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On
 Behalf Of Paolo Bonzini
 Sent: Tuesday, May 28, 2013 4:01 PM
 To: Wenchao Xia
 Cc: as...@redhat.com; qemu-devel@nongnu.org; n...@linux-iscsi.org;
 Michael S. Tsirkin
 Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
 tcm_vhost Linux kernel module
 
 Il 28/05/2013 09:13, Wenchao Xia ha scritto:
   From: Nicholas Bellinger n...@linux-iscsi.org
  
   The WWPN specified in configfs is passed to -device vhost-scsi-pci.
   The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
   available from the QEMU command-line.  Instead, I hardcode it to
 zero.
  
  Hi, Paolo
Any document about how to config it correctly in configfs, before
  invoking qemu with the WWPN number?
 
 Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
 iSCSI for example) so it's quite simple.  Here is an example:
 
 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
 
 The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
 target WWN that you have to pass to -device vhost-scsi-pci.
 
 Paolo




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-06-19 Thread Asias He
On Wed, Jun 19, 2013 at 12:55:10PM +, Libaiqing wrote:
 Hi paolo,
   The vhost-scsi device can be used as boot device?
   I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
   Could you give me some advise to debug this problem ? I can provide more 
 information if need.

Boot from vhost-scsi is supposed to work. The seabios you used should be
fine which contains the fixes for vhost-scsi.

Instead of playing with the /sys/kernel/config/target directly, I really
recommend using targetcli utils.

Nab, I think we really should write some docs for people to use
vhost-scsi.

This is how I install and use targetcli in RHEL6. Note you need upstream
kernel and qemu bits for vhost-scsi.

# yum groupinstall  'Development tools'
# yum install python-devel epydoc python-simpleparse

# git clone git://github.com/agrover/rtslib-fb.git
# git clone git://github.com/agrover/targetcli-fb.git
# git clone git://github.com/agrover/configshell-fb.git
# for i in rtslib-fb configshell-fb targetcli-fb; do
make -C $i rpm
yum localinstall $i/dist/*.noarch.rpm
  done

In targetcli, create a backstore and vhost wwpn, e.g.
# targetcli
/ /backstores/ramdisk create r0 1g
/ /vhost create
/ cd /vhost/naa.500140527cb6616b/tpg1/luns
/ create /backstores/ramdisk/r0

# qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...

Hope this helps.

 Regards,
 baiqing
 
  -Original Message-
  From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
  [mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On
  Behalf Of Paolo Bonzini
  Sent: Tuesday, May 28, 2013 4:01 PM
  To: Wenchao Xia
  Cc: as...@redhat.com; qemu-devel@nongnu.org; n...@linux-iscsi.org;
  Michael S. Tsirkin
  Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
  tcm_vhost Linux kernel module
  
  Il 28/05/2013 09:13, Wenchao Xia ha scritto:
From: Nicholas Bellinger n...@linux-iscsi.org
   
The WWPN specified in configfs is passed to -device vhost-scsi-pci.
The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
available from the QEMU command-line.  Instead, I hardcode it to
  zero.
   
   Hi, Paolo
 Any document about how to config it correctly in configfs, before
   invoking qemu with the WWPN number?
  
  Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
  iSCSI for example) so it's quite simple.  Here is an example:
  
  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
  
  The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
  target WWN that you have to pass to -device vhost-scsi-pci.
  
  Paolo
 

-- 
Asias



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-06-19 Thread Wenchao Xia

于 2013-6-20 9:33, Asias He 写道:

On Wed, Jun 19, 2013 at 12:55:10PM +, Libaiqing wrote:

Hi paolo,
   The vhost-scsi device can be used as boot device?
   I tested with your config + 3.10 rc6 + seabios 1.7.2.2,but failed.
   Could you give me some advise to debug this problem ? I can provide more 
information if need.


Boot from vhost-scsi is supposed to work. The seabios you used should be
fine which contains the fixes for vhost-scsi.

Instead of playing with the /sys/kernel/config/target directly, I really
recommend using targetcli utils.

Nab, I think we really should write some docs for people to use
vhost-scsi.


  A section in qemu-options.hx would be great, currently an example is
good enough to me.



This is how I install and use targetcli in RHEL6. Note you need upstream
kernel and qemu bits for vhost-scsi.

# yum groupinstall  'Development tools'
# yum install python-devel epydoc python-simpleparse

# git clone git://github.com/agrover/rtslib-fb.git
# git clone git://github.com/agrover/targetcli-fb.git
# git clone git://github.com/agrover/configshell-fb.git
# for i in rtslib-fb configshell-fb targetcli-fb; do
make -C $i rpm
yum localinstall $i/dist/*.noarch.rpm
   done

In targetcli, create a backstore and vhost wwpn, e.g.
# targetcli
/ /backstores/ramdisk create r0 1g
/ /vhost create
/ cd /vhost/naa.500140527cb6616b/tpg1/luns
/ create /backstores/ramdisk/r0

# qemu -device vhost-scsi-pci,wwpn=naa.500140527cb6616b ...

Hope this helps.


Regards,
baiqing


-Original Message-
From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
[mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On
Behalf Of Paolo Bonzini
Sent: Tuesday, May 28, 2013 4:01 PM
To: Wenchao Xia
Cc: as...@redhat.com; qemu-devel@nongnu.org; n...@linux-iscsi.org;
Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the
tcm_vhost Linux kernel module

Il 28/05/2013 09:13, Wenchao Xia ha scritto:

From: Nicholas Bellinger n...@linux-iscsi.org

The WWPN specified in configfs is passed to -device vhost-scsi-pci.
The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
available from the QEMU command-line.  Instead, I hardcode it to

zero.



Hi, Paolo
   Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?


Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:

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

The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
target WWN that you have to pass to -device vhost-scsi-pci.

Paolo







--
Best Regards

Wenchao Xia




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-30 Thread Badari Pulavarty

On 05/29/2013 10:36 PM, Nicholas A. Bellinger wrote:

On Wed, 2013-05-29 at 21:29 -0700, Nicholas A. Bellinger wrote:

On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:

On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:

On 05/29/2013 02:05 AM, Wenchao Xia wrote:

于 2013-5-28 17:00, Wenchao Xia 写道:

SNIP


  I have done a basic test of vhost-scsi, following is the result I'd
like to post, generally it seems fine:

Result:
  fdisk/mkfs: fdisk can find it, mke2fs works fine.
  mount: can mount it.
  file I/O: dd 90M zero to a file in that disk succeed.



I tried without nested kvm.


Issues:
  1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
dev  fd0, sector 0, I guess it is caused by nested KVM that failed
to kick host kernel?


I don't see this issue. Are you sure fd0 is actually the scsi device ?
what is fd0 ?


  2) in fdisk -l, it shows 512 bytes larger than the parameter I
specified in fd_dev_size parameter in configfs on host.(shows
104858112 bytes, see the invocation script below)


I see the same. For some reason fdisk -l in the VM shows
512-bytes more than the actual size for the file (on the host).

Hmm, interesting. Will look into it.

Nick, Any ideas here?


Mmm, fd_get_blocks() is not returning the expected minus one logical
blocks with a !S_ISBLK() setup.

This is happening for every other backend -get_blocks() call already,
and should be happening for the fd_dev_size case as well.

Applying the following to target-pending.git now.


Actually sorry, that last patch is not correct..

Here's a better one to properly set fd_dev-fd_block_size at configure
time, and use dev_attrib.block_size in fd_get_blocks() to allow for user
defined block_sizes.

Thanks,

--nab

commit 9e309f9307fe644dee8718980bfcb77de91ce38e
Author: Nicholas Bellinger n...@linux-iscsi.org
Date:   Wed May 29 21:35:23 2013 -0700

 target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export
 
 This patch fixes a bug where FILEIO was incorrectly reporting the number

 of logical blocks (+ 1) when using non struct block_device export mode.
 
 It changes fd_get_blocks() to follow all other backend -get_blocks() cases,

 and reduces the calculated dev_size by one dev-dev_attrib.block_size
 number of bytes, and fixes the initial block_size assignment within
 fd_configure_device()
 
 Reported-by: Wenchao Xia xiaw...@linux.vnet.ibm.com

 Reported-by: Badari Pulavarty pbad...@us.ibm.com
 Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 1b1d544..b11890d 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -153,6 +153,7 @@ static int fd_configure_device(struct se_device *dev)
 struct request_queue *q = bdev_get_queue(inode-i_bdev);
 unsigned long long dev_size;

+   fd_dev-fd_block_size = bdev_logical_block_size(inode-i_bdev);
 /*
  * Determine the number of bytes from i_size_read() minus
  * one (1) logical sector from underlying struct block_device
@@ -199,6 +200,7 @@ static int fd_configure_device(struct se_device *dev)
 goto fail;
 }

+   fd_dev-fd_block_size = FD_BLOCKSIZE;
 /*
  * Limit UNMAP emulation to 8k Number of LBAs (NoLB)
  */
@@ -217,9 +219,7 @@ static int fd_configure_device(struct se_device *dev)
 dev-dev_attrib.max_write_same_len = 0x1000;
 }

-   fd_dev-fd_block_size = dev-dev_attrib.hw_block_size;
-
-   dev-dev_attrib.hw_block_size = FD_BLOCKSIZE;
+   dev-dev_attrib.hw_block_size = fd_dev-fd_block_size;
 dev-dev_attrib.hw_max_sectors = FD_MAX_SECTORS;
 dev-dev_attrib.hw_queue_depth = FD_MAX_DEVICE_QUEUE_DEPTH;

@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
  * to handle underlying block_device resize operations.
  */
 if (S_ISBLK(i-i_mode))
-   dev_size = (i_size_read(i) - fd_dev-fd_block_size);
+   dev_size = i_size_read(i);
 else
 dev_size = fd_dev-fd_dev_size;

-   return div_u64(dev_size, dev-dev_attrib.block_size);
+   return div_u64(dev_size - dev-dev_attrib.block_size,
+  dev-dev_attrib.block_size);
  }

  static struct sbc_ops fd_sbc_ops = {



Verified and it shows the correct value now.

Thanks,
Badari




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Wenchao Xia

于 2013-5-28 17:00, Wenchao Xia 写道:

于 2013-5-28 16:33, Asias He 写道:

On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:

Il 28/05/2013 09:13, Wenchao Xia ha scritto:

From: Nicholas Bellinger n...@linux-iscsi.org

The WWPN specified in configfs is passed to -device vhost-scsi-pci.
The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
not
available from the QEMU command-line.  Instead, I hardcode it to
zero.


Hi, Paolo
   Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?


Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:

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

The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
target WWN that you have to pass to -device vhost-scsi-pci.

Paolo


For me, I always use targetcli utils instead of the sysfs interface.
targetcli in F18 has vhost support now.


   Thanks very much for above information, I'll try it for test.


  I have done a basic test of vhost-scsi, following is the result I'd
like to post, generally it seems fine:

Result:
  fdisk/mkfs: fdisk can find it, mke2fs works fine.
  mount: can mount it.
  file I/O: dd 90M zero to a file in that disk succeed.

Issues:
  1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
dev  fd0, sector 0, I guess it is caused by nested KVM that failed
to kick host kernel?
  2) in fdisk -l, it shows 512 bytes larger than the parameter I
specified in fd_dev_size parameter in configfs on host.(shows
104858112 bytes, see the invocation script below)

ENV:
 nested KVM:

   RH6.4
(Qemu Virtual CPU 1.5.50, Linux 3.10.0.rc3)
  |  (100M vhost-scsi hooked with file backend)
   RH6.4
(Common KVM processer, Linux 3.10.0.rc3,
qemu-system-x86_64 1.5.50+, 6a4e17711442849bf2cc731ccddef5a2a2d92d29,
seabios 1.7.2.2, e9725dd76d5d7212cb4a97fd18ff2599538955cf)
  |
  Fefora 18
(Intel Xeon X5650, Linux version 3.8.11-200.fc18.x86_64,
 QEMU emulator version 1.2.2)

Invocation details:
  On RH6.4 host:
  1  with root, execute following script to prepare configfs system:

FILEIO=fileio_1
IMAGE=/home/xiawenc/Work/qemu/test/test1.raw
SIZE=104857600
QEMU_WWPN=naa.600140554cf3a1fe
NEXUS=naa.60014053226f03f8

mkdir -p /sys/kernel/config/target/core/$FILEIO/fileio
echo fd_dev_name=$IMAGE,fd_dev_size=$SIZE  
/sys/kernel/config/target/core/$FILEIO/fileio/control

echo 1  /sys/kernel/config/target/core/$FILEIO/fileio/enable

mkdir -p /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0
ln -sf /sys/kernel/config/target/core/$FILEIO/fileio/ 
/sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0/virtual_scsi_port

echo $NEXUS  /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/nexus

  2 invoke qemu, test_guest_RH64.qcow2 is a pre-made disk containing
RH6.4 system:

x86_64-softmmu/qemu-system-x86_64 --enablem 1024 -drive 
file=/mnt/nfs/test_guest_RH64.qcow2,if=ide,cache=writethrough -vnc 
0.0.0.0:10 -L mybios/ -device 
vhost-scsi-pci,wwpn=naa.600140554cf3a1fe,event_idx=off



--
Best Regards

Wenchao Xia




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Asias He
On Wed, May 29, 2013 at 05:05:31PM +0800, Wenchao Xia wrote:
 于 2013-5-28 17:00, Wenchao Xia 写道:
 于 2013-5-28 16:33, Asias He 写道:
 On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
 Il 28/05/2013 09:13, Wenchao Xia ha scritto:
 From: Nicholas Bellinger n...@linux-iscsi.org
 
 The WWPN specified in configfs is passed to -device vhost-scsi-pci.
 The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
 not
 available from the QEMU command-line.  Instead, I hardcode it to
 zero.
 
 Hi, Paolo
Any document about how to config it correctly in configfs, before
 invoking qemu with the WWPN number?
 
 Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
 iSCSI for example) so it's quite simple.  Here is an example:
 
 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
 
 The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
 target WWN that you have to pass to -device vhost-scsi-pci.
 
 Paolo
 
 For me, I always use targetcli utils instead of the sysfs interface.
 targetcli in F18 has vhost support now.
 
Thanks very much for above information, I'll try it for test.
 
   I have done a basic test of vhost-scsi, following is the result I'd
 like to post, generally it seems fine:
 
 Result:
   fdisk/mkfs: fdisk can find it, mke2fs works fine.
   mount: can mount it.
   file I/O: dd 90M zero to a file in that disk succeed.
 
 Issues:
   1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
 dev  fd0, sector 0, I guess it is caused by nested KVM that failed
 to kick host kernel?

Did you run without nested KVM?

   2) in fdisk -l, it shows 512 bytes larger than the parameter I
 specified in fd_dev_size parameter in configfs on host.(shows
 104858112 bytes, see the invocation script below)

Does targetcli give you the correct size? Also, to narrow the issue down,
you can try other backstores, e.g block or ramdisk.

 ENV:
  nested KVM:
 
RH6.4
 (Qemu Virtual CPU 1.5.50, Linux 3.10.0.rc3)
   |  (100M vhost-scsi hooked with file backend)
RH6.4
 (Common KVM processer, Linux 3.10.0.rc3,
 qemu-system-x86_64 1.5.50+, 6a4e17711442849bf2cc731ccddef5a2a2d92d29,
 seabios 1.7.2.2, e9725dd76d5d7212cb4a97fd18ff2599538955cf)
   |
   Fefora 18
 (Intel Xeon X5650, Linux version 3.8.11-200.fc18.x86_64,
  QEMU emulator version 1.2.2)
 
 Invocation details:
   On RH6.4 host:
   1  with root, execute following script to prepare configfs system:
 
 FILEIO=fileio_1
 IMAGE=/home/xiawenc/Work/qemu/test/test1.raw
 SIZE=104857600
 QEMU_WWPN=naa.600140554cf3a1fe
 NEXUS=naa.60014053226f03f8
 
 mkdir -p /sys/kernel/config/target/core/$FILEIO/fileio
 echo fd_dev_name=$IMAGE,fd_dev_size=$SIZE 
 /sys/kernel/config/target/core/$FILEIO/fileio/control
 echo 1  /sys/kernel/config/target/core/$FILEIO/fileio/enable
 
 mkdir -p /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0
 ln -sf /sys/kernel/config/target/core/$FILEIO/fileio/ 
 /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/lun/lun_0/virtual_scsi_port
 echo $NEXUS  /sys/kernel/config/target/vhost/$QEMU_WWPN/tpgt_0/nexus
 
   2 invoke qemu, test_guest_RH64.qcow2 is a pre-made disk containing
 RH6.4 system:
 
 x86_64-softmmu/qemu-system-x86_64 --enablem 1024 -drive
 file=/mnt/nfs/test_guest_RH64.qcow2,if=ide,cache=writethrough -vnc
 0.0.0.0:10 -L mybios/ -device
 vhost-scsi-pci,wwpn=naa.600140554cf3a1fe,event_idx=off
 
 
 -- 
 Best Regards
 
 Wenchao Xia
 

-- 
Asias



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Badari Pulavarty

On 05/29/2013 02:05 AM, Wenchao Xia wrote:

于 2013-5-28 17:00, Wenchao Xia 写道:

于 2013-5-28 16:33, Asias He 写道:

On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:

Il 28/05/2013 09:13, Wenchao Xia ha scritto:

From: Nicholas Bellinger n...@linux-iscsi.org

The WWPN specified in configfs is passed to -device 
vhost-scsi-pci.

The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
not
available from the QEMU command-line.  Instead, I hardcode it to
zero.


Hi, Paolo
   Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?


Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:

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

The nexus value is the initiator WWN. naa.600140554cf3a18e is the
target WWN that you have to pass to -device vhost-scsi-pci.

Paolo


For me, I always use targetcli utils instead of the sysfs interface.
targetcli in F18 has vhost support now.


   Thanks very much for above information, I'll try it for test.


  I have done a basic test of vhost-scsi, following is the result I'd
like to post, generally it seems fine:

Result:
  fdisk/mkfs: fdisk can find it, mke2fs works fine.
  mount: can mount it.
  file I/O: dd 90M zero to a file in that disk succeed.




I tried without nested kvm.



Issues:
  1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
dev  fd0, sector 0, I guess it is caused by nested KVM that failed
to kick host kernel?



I don't see this issue. Are you sure fd0 is actually the scsi device ?
what is fd0 ?


  2) in fdisk -l, it shows 512 bytes larger than the parameter I
specified in fd_dev_size parameter in configfs on host.(shows
104858112 bytes, see the invocation script below)



I see the same. For some reason fdisk -l in the VM shows
512-bytes more than the actual size for the file (on the host).

Thanks,
Badari




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Asias He
On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
 On 05/29/2013 02:05 AM, Wenchao Xia wrote:
 于 2013-5-28 17:00, Wenchao Xia 写道:
 于 2013-5-28 16:33, Asias He 写道:
 On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
 Il 28/05/2013 09:13, Wenchao Xia ha scritto:
 From: Nicholas Bellinger n...@linux-iscsi.org
 
 The WWPN specified in configfs is passed to -device
 vhost-scsi-pci.
 The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
 not
 available from the QEMU command-line.  Instead, I hardcode it to
 zero.
 
 Hi, Paolo
Any document about how to config it correctly in configfs, before
 invoking qemu with the WWPN number?
 
 Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
 iSCSI for example) so it's quite simple.  Here is an example:
 
 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
 
 The nexus value is the initiator WWN. naa.600140554cf3a18e is the
 target WWN that you have to pass to -device vhost-scsi-pci.
 
 Paolo
 
 For me, I always use targetcli utils instead of the sysfs interface.
 targetcli in F18 has vhost support now.
 
Thanks very much for above information, I'll try it for test.
 
   I have done a basic test of vhost-scsi, following is the result I'd
 like to post, generally it seems fine:
 
 Result:
   fdisk/mkfs: fdisk can find it, mke2fs works fine.
   mount: can mount it.
   file I/O: dd 90M zero to a file in that disk succeed.
 
 
 
 I tried without nested kvm.
 
 
 Issues:
   1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
 dev  fd0, sector 0, I guess it is caused by nested KVM that failed
 to kick host kernel?
 
 
 I don't see this issue. Are you sure fd0 is actually the scsi device ?
 what is fd0 ?
 
   2) in fdisk -l, it shows 512 bytes larger than the parameter I
 specified in fd_dev_size parameter in configfs on host.(shows
 104858112 bytes, see the invocation script below)
 
 
 I see the same. For some reason fdisk -l in the VM shows
 512-bytes more than the actual size for the file (on the host).

Hmm, interesting. Will look into it.

Nick, Any ideas here?

 Thanks,
 Badari
 

-- 
Asias



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Wenchao Xia
于 2013-5-29 23:10, Badari Pulavarty 写道:
 On 05/29/2013 02:05 AM, Wenchao Xia wrote:
 于 2013-5-28 17:00, Wenchao Xia 写道:
 于 2013-5-28 16:33, Asias He 写道:
 On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
 Il 28/05/2013 09:13, Wenchao Xia ha scritto:
 From: Nicholas Bellinger n...@linux-iscsi.org

 The WWPN specified in configfs is passed to -device 
 vhost-scsi-pci.
 The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
 not
 available from the QEMU command-line.  Instead, I hardcode it to
 zero.

 Hi, Paolo
Any document about how to config it correctly in configfs, before
 invoking qemu with the WWPN number?

 Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
 iSCSI for example) so it's quite simple.  Here is an example:

 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

 The nexus value is the initiator WWN. naa.600140554cf3a18e is the
 target WWN that you have to pass to -device vhost-scsi-pci.

 Paolo

 For me, I always use targetcli utils instead of the sysfs interface.
 targetcli in F18 has vhost support now.

Thanks very much for above information, I'll try it for test.

   I have done a basic test of vhost-scsi, following is the result I'd
 like to post, generally it seems fine:

 Result:
   fdisk/mkfs: fdisk can find it, mke2fs works fine.
   mount: can mount it.
   file I/O: dd 90M zero to a file in that disk succeed.
 
 
 
 I tried without nested kvm.
 

 Issues:
   1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
 dev  fd0, sector 0, I guess it is caused by nested KVM that failed
 to kick host kernel?
 
 
 I don't see this issue. Are you sure fd0 is actually the scsi device ?
 what is fd0 ?
 
  I am not sure, it just come out from dmesg when fdisk -l hung, and
following line is sdb which is the vhost-scsi device, and fdisk
printing stopped before sdb for a few seconds, so I think it's it.
it happened once after my partition operation.
  My instinct opinion is it happens only in nested KVM when host
missed a kick, since following I/O can succeed. Sadly I have no
bare-metal at hand to test as a comparation.

   2) in fdisk -l, it shows 512 bytes larger than the parameter I
 specified in fd_dev_size parameter in configfs on host.(shows
 104858112 bytes, see the invocation script below)

 
 I see the same. For some reason fdisk -l in the VM shows
 512-bytes more than the actual size for the file (on the host).
 
 Thanks,
 Badari
 


-- 
Best Regards

Wenchao Xia




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Nicholas A. Bellinger
On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
 On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
  On 05/29/2013 02:05 AM, Wenchao Xia wrote:
  于 2013-5-28 17:00, Wenchao Xia 写道:

SNIP

I have done a basic test of vhost-scsi, following is the result I'd
  like to post, generally it seems fine:
  
  Result:
fdisk/mkfs: fdisk can find it, mke2fs works fine.
mount: can mount it.
file I/O: dd 90M zero to a file in that disk succeed.
  
  
  
  I tried without nested kvm.
  
  
  Issues:
1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
  dev  fd0, sector 0, I guess it is caused by nested KVM that failed
  to kick host kernel?
  
  
  I don't see this issue. Are you sure fd0 is actually the scsi device ?
  what is fd0 ?
  
2) in fdisk -l, it shows 512 bytes larger than the parameter I
  specified in fd_dev_size parameter in configfs on host.(shows
  104858112 bytes, see the invocation script below)
  
  
  I see the same. For some reason fdisk -l in the VM shows
  512-bytes more than the actual size for the file (on the host).
 
 Hmm, interesting. Will look into it.
 
 Nick, Any ideas here?
 

Mmm, fd_get_blocks() is not returning the expected minus one logical
blocks with a !S_ISBLK() setup.

This is happening for every other backend -get_blocks() call already,
and should be happening for the fd_dev_size case as well.

Applying the following to target-pending.git now.

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 1b1d544..8a2ac90 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
 * to handle underlying block_device resize operations.
 */
if (S_ISBLK(i-i_mode))
-   dev_size = (i_size_read(i) - fd_dev-fd_block_size);
+   dev_size = i_size_read(i);
else
dev_size = fd_dev-fd_dev_size;
 
-   return div_u64(dev_size, dev-dev_attrib.block_size);
+   return div_u64(dev_size - fd_dev-fd_block_size,
+  dev-dev_attrib.block_size);
 }
 
 static struct sbc_ops fd_sbc_ops = {




Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-29 Thread Nicholas A. Bellinger
On Wed, 2013-05-29 at 21:29 -0700, Nicholas A. Bellinger wrote:
 On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
  On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
   On 05/29/2013 02:05 AM, Wenchao Xia wrote:
   于 2013-5-28 17:00, Wenchao Xia 写道:
 
 SNIP
 
 I have done a basic test of vhost-scsi, following is the result I'd
   like to post, generally it seems fine:
   
   Result:
 fdisk/mkfs: fdisk can find it, mke2fs works fine.
 mount: can mount it.
 file I/O: dd 90M zero to a file in that disk succeed.
   
   
   
   I tried without nested kvm.
   
   
   Issues:
 1) in fdisk -l, sometime timeout with dmesg end_request: I/O error,
   dev  fd0, sector 0, I guess it is caused by nested KVM that failed
   to kick host kernel?
   
   
   I don't see this issue. Are you sure fd0 is actually the scsi device ?
   what is fd0 ?
   
 2) in fdisk -l, it shows 512 bytes larger than the parameter I
   specified in fd_dev_size parameter in configfs on host.(shows
   104858112 bytes, see the invocation script below)
   
   
   I see the same. For some reason fdisk -l in the VM shows
   512-bytes more than the actual size for the file (on the host).
  
  Hmm, interesting. Will look into it.
  
  Nick, Any ideas here?
  
 
 Mmm, fd_get_blocks() is not returning the expected minus one logical
 blocks with a !S_ISBLK() setup.
 
 This is happening for every other backend -get_blocks() call already,
 and should be happening for the fd_dev_size case as well.
 
 Applying the following to target-pending.git now.
 

Actually sorry, that last patch is not correct..

Here's a better one to properly set fd_dev-fd_block_size at configure
time, and use dev_attrib.block_size in fd_get_blocks() to allow for user
defined block_sizes.

Thanks,

--nab

commit 9e309f9307fe644dee8718980bfcb77de91ce38e
Author: Nicholas Bellinger n...@linux-iscsi.org
Date:   Wed May 29 21:35:23 2013 -0700

target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export

This patch fixes a bug where FILEIO was incorrectly reporting the number
of logical blocks (+ 1) when using non struct block_device export mode.

It changes fd_get_blocks() to follow all other backend -get_blocks() cases,
and reduces the calculated dev_size by one dev-dev_attrib.block_size
number of bytes, and fixes the initial block_size assignment within
fd_configure_device()

Reported-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Reported-by: Badari Pulavarty pbad...@us.ibm.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 1b1d544..b11890d 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -153,6 +153,7 @@ static int fd_configure_device(struct se_device *dev)
struct request_queue *q = bdev_get_queue(inode-i_bdev);
unsigned long long dev_size;
 
+   fd_dev-fd_block_size = bdev_logical_block_size(inode-i_bdev);
/*
 * Determine the number of bytes from i_size_read() minus
 * one (1) logical sector from underlying struct block_device
@@ -199,6 +200,7 @@ static int fd_configure_device(struct se_device *dev)
goto fail;
}
 
+   fd_dev-fd_block_size = FD_BLOCKSIZE;
/*
 * Limit UNMAP emulation to 8k Number of LBAs (NoLB)
 */
@@ -217,9 +219,7 @@ static int fd_configure_device(struct se_device *dev)
dev-dev_attrib.max_write_same_len = 0x1000;
}
 
-   fd_dev-fd_block_size = dev-dev_attrib.hw_block_size;
-
-   dev-dev_attrib.hw_block_size = FD_BLOCKSIZE;
+   dev-dev_attrib.hw_block_size = fd_dev-fd_block_size;
dev-dev_attrib.hw_max_sectors = FD_MAX_SECTORS;
dev-dev_attrib.hw_queue_depth = FD_MAX_DEVICE_QUEUE_DEPTH;
 
@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
 * to handle underlying block_device resize operations.
 */
if (S_ISBLK(i-i_mode))
-   dev_size = (i_size_read(i) - fd_dev-fd_block_size);
+   dev_size = i_size_read(i);
else
dev_size = fd_dev-fd_dev_size;
 
-   return div_u64(dev_size, dev-dev_attrib.block_size);
+   return div_u64(dev_size - dev-dev_attrib.block_size,
+  dev-dev_attrib.block_size);
 }
 
 static struct sbc_ops fd_sbc_ops = {





Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-28 Thread Wenchao Xia
于 2013-4-19 22:24, Paolo Bonzini 写道:
 From: Nicholas Bellinger n...@linux-iscsi.org
 
 The WWPN specified in configfs is passed to -device vhost-scsi-pci.
 The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
 available from the QEMU command-line.  Instead, I hardcode it to zero.
 
Hi, Paolo
  Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?


 Changes in Patch-v2:
 - Add vhost_scsi_get_features() in order to determine feature bits
   supports by host kernel (mst + nab)
 - Re-enable usage of DEFINE_VIRTIO_COMMON_FEATURES, and allow
   EVENT_IDX to be disabled by host in vhost_scsi_get_features()
 - Drop unused hotplug bit in DEFINE_VHOST_SCSI_PROPERTIES
 
 Changes in Patch-v1:
 - Set event_idx=off by default (nab, thanks asias)
 - Disable hotplug feature bit for v3.9 tcm_vhost kernel code, need to
   re-enable in v3.10 (nab)
 - Update to latest qemu.git/master HEAD
 
 Changes in WIP-V3:
 - Drop ioeventfd vhost_scsi_properties (asias, thanks stefanha)
 - Add CONFIG_VHOST_SCSI (asias, thanks stefanha)
 - Add hotplug feature bit
 
 Changes in WIP-V2:
 - Add backend guest masking support (nab)
 - Bump ABI_VERSION to 1 (nab)
 - Set up set_guest_notifiers (asias)
 - Set up vs-dev.vq_index (asias)
 - Drop vs-vs.vdev.{set,clear}_vhost_endpoint (asias)
 - Drop VIRTIO_CONFIG_S_DRIVER check in vhost_scsi_set_status (asias)
 
 Howto:
 Use the latest seabios, at least commit b44a7be17b
 git clone git://git.seabios.org/seabios.git
 make
 cp out/bios.bin /usr/share/qemu/bios.bin
 qemu -device vhost-scsi-pci,wwpn=naa.6001405bd4e8476d
 ...
 
 Cc: Michael S. Tsirkin m...@redhat.com
 Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
 Signed-off-by: Asias He as...@redhat.com
 [ Rebase on top of VirtIOSCSICommon patch, fix bugs in feature
negotiation and irqfd masking - Paolo ]
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
   configure   |  10 ++
   hw/scsi/Makefile.objs   |   6 +-
   hw/scsi/vhost-scsi.c| 288 
 
   include/hw/virtio/vhost-scsi.h  |  73 ++
   include/hw/virtio/virtio-scsi.h |   2 +
   5 files changed, 378 insertions(+), 1 deletion(-)
   create mode 100644 hw/scsi/vhost-scsi.c
   create mode 100644 include/hw/virtio/vhost-scsi.h
 
 diff --git a/configure b/configure
 index ed49f91..51a6c56 100755
 --- a/configure
 +++ b/configure
 @@ -179,6 +179,7 @@ libattr=
   xfs=
 
   vhost_net=no
 +vhost_scsi=no
   kvm=no
   gprof=no
   debug_tcg=no
 @@ -543,6 +544,7 @@ Haiku)
 usb=linux
 kvm=yes
 vhost_net=yes
 +  vhost_scsi=yes
 if [ $cpu = i386 -o $cpu = x86_64 ] ; then
   audio_possible_drivers=$audio_possible_drivers fmod
 fi
 @@ -870,6 +872,10 @@ for opt do
 ;;
 --enable-vhost-net) vhost_net=yes
 ;;
 +  --disable-vhost-scsi) vhost_scsi=no
 +  ;;
 +  --enable-vhost-scsi) vhost_scsi=yes
 +  ;;
 --disable-glx) glx=no
 ;;
 --enable-glx) glx=yes
 @@ -3553,6 +3559,7 @@ echo sigev_thread_id   $sigev_thread_id
   echo uuid support  $uuid
   echo libcap-ng support $cap_ng
   echo vhost-net support $vhost_net
 +echo vhost-scsi support $vhost_scsi
   echo Trace backend $trace_backend
   echo Trace output file $trace_file-pid
   echo spice support $spice 
 ($spice_protocol_version/$spice_server_version)
 @@ -3836,6 +3843,9 @@ fi
   if test $virtfs = yes ; then
 echo CONFIG_VIRTFS=y  $config_host_mak
   fi
 +if test $vhost_scsi = yes ; then
 +  echo CONFIG_VHOST_SCSI=y  $config_host_mak
 +fi
   if test $blobs = yes ; then
 echo INSTALL_BLOBS=yes  $config_host_mak
   fi
 diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
 index eaec6c8..121ddc5 100644
 --- a/hw/scsi/Makefile.objs
 +++ b/hw/scsi/Makefile.objs
 @@ -6,4 +6,8 @@ common-obj-$(CONFIG_VMW_PVSCSI_SCSI_PCI) += vmw_pvscsi.o
   common-obj-$(CONFIG_ESP) += esp.o
   common-obj-$(CONFIG_ESP_PCI) += esp-pci.o
   obj-$(CONFIG_PSERIES) += spapr_vscsi.o
 -obj-$(CONFIG_VIRTIO) += virtio-scsi.o
 +
 +ifeq ($(CONFIG_VIRTIO),y)
 +obj-y += virtio-scsi.o
 +obj-$(CONFIG_VHOST_SCSI) += vhost-scsi.o
 +endif
 diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
 new file mode 100644
 index 000..3dd1a0f
 --- /dev/null
 +++ b/hw/scsi/vhost-scsi.c
 @@ -0,0 +1,288 @@
 +/*
 + * vhost_scsi host device
 + *
 + * Copyright IBM, Corp. 2011
 + *
 + * Authors:
 + *  Stefan Hajnoczi   stefa...@linux.vnet.ibm.com
 + *
 + * Changes for QEMU mainline + tcm_vhost kernel upstream:
 + *  Nicholas Bellinger n...@risingtidesystems.com
 + *
 + * This work is licensed under the terms of the GNU LGPL, version 2 or later.
 + * See the COPYING.LIB file in the top-level directory.
 + *
 + */
 +
 +#include sys/ioctl.h
 +#include config.h
 +#include qemu/queue.h
 +#include monitor/monitor.h
 +#include migration/migration.h
 +#include hw/virtio/vhost-scsi.h
 +#include 

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-28 Thread Paolo Bonzini
Il 28/05/2013 09:13, Wenchao Xia ha scritto:
  From: Nicholas Bellinger n...@linux-iscsi.org
  
  The WWPN specified in configfs is passed to -device vhost-scsi-pci.
  The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
  available from the QEMU command-line.  Instead, I hardcode it to zero.
  
 Hi, Paolo
   Any document about how to config it correctly in configfs, before
 invoking qemu with the WWPN number?

Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:

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

The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
target WWN that you have to pass to -device vhost-scsi-pci.

Paolo



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-28 Thread Asias He
On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
 Il 28/05/2013 09:13, Wenchao Xia ha scritto:
   From: Nicholas Bellinger n...@linux-iscsi.org
   
   The WWPN specified in configfs is passed to -device vhost-scsi-pci.
   The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
   available from the QEMU command-line.  Instead, I hardcode it to zero.
   
  Hi, Paolo
Any document about how to config it correctly in configfs, before
  invoking qemu with the WWPN number?
 
 Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
 iSCSI for example) so it's quite simple.  Here is an example:
 
 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
 
 The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
 target WWN that you have to pass to -device vhost-scsi-pci.
 
 Paolo

For me, I always use targetcli utils instead of the sysfs interface.
targetcli in F18 has vhost support now.

-- 
Asias



Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

2013-05-28 Thread Wenchao Xia

于 2013-5-28 16:33, Asias He 写道:

On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:

Il 28/05/2013 09:13, Wenchao Xia ha scritto:

From: Nicholas Bellinger n...@linux-iscsi.org

The WWPN specified in configfs is passed to -device vhost-scsi-pci.
The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is not
available from the QEMU command-line.  Instead, I hardcode it to zero.


Hi, Paolo
   Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?


Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:

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

The nexus value is the initiator WWN.  naa.600140554cf3a18e is the
target WWN that you have to pass to -device vhost-scsi-pci.

Paolo


For me, I always use targetcli utils instead of the sysfs interface.
targetcli in F18 has vhost support now.


  Thanks very much for above information, I'll try it for test.

--
Best Regards

Wenchao Xia