From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XifU8-0000vV-Aa for qemu-devel@nongnu.org; Mon, 27 Oct 2014 04:17:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XifU3-00029G-Bw for qemu-devel@nongnu.org; Mon, 27 Oct 2014 04:17:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XifU3-00029A-4w for qemu-devel@nongnu.org; Mon, 27 Oct 2014 04:16:59 -0400 Message-ID: <544DFF71.5070200@redhat.com> Date: Mon, 27 Oct 2014 09:16:49 +0100 From: Max Reitz MIME-Version: 1.0 References: <1413446090-30050-1-git-send-email-pl@kamp.de> <1413446090-30050-4-git-send-email-pl@kamp.de> <5448E403.30602@redhat.com> <544BBEB5.4040004@kamp.de> In-Reply-To: <544BBEB5.4040004@kamp.de> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv4 3/4] block/iscsi: set max_transfer_length List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, ronniesahlberg@gmail.com, stefanha@redhat.com On 2014-10-25 at 17:16, Peter Lieven wrote: > Am 23.10.2014 um 13:18 schrieb Max Reitz: >> On 2014-10-16 at 09:54, Peter Lieven wrote: >>> the limit of 0xffffff for 16 byte CDBs is intentional to >>> avoid overflows on 32-bit architectures. >> How is it related to 32 bit? I somehow feel like it has to do something with the result of sector_lun2qemu() which involves block_size... > iscsilun->bl.max_xfer_len is 32-bit unsigned while nb_sectors is usually signed. Furthermore as you suspected nb_sectors is always 512Byte sectors > while iscsilun->block_size can be 4k or even more. > > I will change the code to set max_xfer_len to 0xffffffff and limit the output of sector_lun2qemu() to INT_MAX in the bs->bl.max_transfer_length case. > > However, in real life you will never want to have a transfer of 0x3fffffff blocks, won't you? I'd be fine with a single block, but QEMU guests matter more than me. :-) I was just wondering how you ended up with 2^24 - 1 as it would be (2^32 - 1) / 256. I do remember IDE doing 16-bit-transfers, so I could imagine how this works out with 512 byte sector size, but this isn't IDE, so... (sorry, it's been a while since I worked with the SCSI protocol myself) Max > Peter > > >>> Signed-off-by: Peter Lieven >>> Reviewed-by: Ronnie Sahlberg >>> --- >>> block/iscsi.c | 12 ++++++++++-- >>> 1 file changed, 10 insertions(+), 2 deletions(-) >>> >>> diff --git a/block/iscsi.c b/block/iscsi.c >>> index 3a01de0..c873d13 100644 >>> --- a/block/iscsi.c >>> +++ b/block/iscsi.c >>> @@ -1449,10 +1449,18 @@ static void iscsi_close(BlockDriverState *bs) >>> static void iscsi_refresh_limits(BlockDriverState *bs, Error **errp) >>> { >>> - IscsiLun *iscsilun = bs->opaque; >>> - >>> /* We don't actually refresh here, but just return data queried in >>> * iscsi_open(): iscsi targets don't change their limits. */ >>> + >>> + IscsiLun *iscsilun = bs->opaque; >>> + uint32_t max_xfer_len = iscsilun->use_16_for_rw ? 0xffffff : 0xffff; >>> + >>> + if (iscsilun->bl.max_xfer_len) { >>> + max_xfer_len = MIN(max_xfer_len, iscsilun->bl.max_xfer_len); >>> + } >>> + >>> + bs->bl.max_transfer_length = sector_lun2qemu(max_xfer_len, iscsilun); >>> + >>> if (iscsilun->lbp.lbpu) { >>> if (iscsilun->bl.max_unmap < 0xffffffff) { >>> bs->bl.max_discard = sector_lun2qemu(iscsilun->bl.max_unmap,