From patchwork Thu May 30 04:29:07 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Nicholas A. Bellinger" X-Patchwork-Id: 247448 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 3C46A2C0096 for ; Thu, 30 May 2013 14:26:14 +1000 (EST) Received: from localhost ([::1]:60685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhuRI-0007kR-6o for incoming@patchwork.ozlabs.org; Thu, 30 May 2013 00:26:12 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhuQy-0007k3-3V for qemu-devel@nongnu.org; Thu, 30 May 2013 00:25:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhuQr-00055m-WE for qemu-devel@nongnu.org; Thu, 30 May 2013 00:25:52 -0400 Received: from mail.linux-iscsi.org ([67.23.28.174]:49021 helo=linux-iscsi.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhuQr-00055V-RC for qemu-devel@nongnu.org; Thu, 30 May 2013 00:25:45 -0400 Received: from [192.168.1.68] (75-37-193-228.lightspeed.lsatca.sbcglobal.net [75.37.193.228]) (using SSLv3 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nab) by linux-iscsi.org (Postfix) with ESMTPSA id 593FF22D9D1; Thu, 30 May 2013 04:12:39 +0000 (UTC) Message-ID: <1369888147.7364.124.camel@haakon3.risingtidesystems.com> From: "Nicholas A. Bellinger" To: Asias He Date: Wed, 29 May 2013 21:29:07 -0700 In-Reply-To: <20130529221721.GC19601@hj.localdomain> References: <1366381460-6041-1-git-send-email-pbonzini@redhat.com> <1366381460-6041-7-git-send-email-pbonzini@redhat.com> <51A4590F.90503@linux.vnet.ibm.com> <51A4644A.6070002@redhat.com> <20130528083352.GA19799@hj.localdomain> <51A47244.9050203@linux.vnet.ibm.com> <51A5C4DB.9040307@linux.vnet.ibm.com> <51A61A74.7050508@us.ibm.com> <20130529221721.GC19601@hj.localdomain> X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 67.23.28.174 Cc: Anthony Liguori , "Michael S. Tsirkin" , qemu-devel@nongnu.org, target-devel , Badari Pulavarty , Paolo Bonzini , Wenchao Xia Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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 写道: > > > 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 = {