From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57106)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ronniesahlberg@gmail.com>) id 1XPwwZ-0008PB-ME
	for qemu-devel@nongnu.org; Fri, 05 Sep 2014 13:05:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ronniesahlberg@gmail.com>) id 1XPwwY-0005zw-KE
	for qemu-devel@nongnu.org; Fri, 05 Sep 2014 13:05:03 -0400
Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:50301)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ronniesahlberg@gmail.com>) id 1XPwwY-0005xS-Cy
	for qemu-devel@nongnu.org; Fri, 05 Sep 2014 13:05:02 -0400
Received: by mail-lb0-f172.google.com with SMTP id c11so5561412lbj.31
	for <qemu-devel@nongnu.org>; Fri, 05 Sep 2014 10:05:00 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <1409935888-18552-1-git-send-email-pl@kamp.de>
References: <1409935888-18552-1-git-send-email-pl@kamp.de>
Date: Fri, 5 Sep 2014 10:05:00 -0700
Message-ID: <CAN05THTn5s7kwoeoXpffQNb1JZsqAGO100K7i_VmxZQ-nia7Eg@mail.gmail.com>
From: ronnie sahlberg <ronniesahlberg@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [PATCH 0/4] introduce max_transfer_length
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Lieven <pl@kamp.de>
Cc: Kevin Wolf <kwolf@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>, Max Reitz <mreitz@redhat.com>

Looks good to me.

(minor question is just why not let default max be 0xffff for both 10
and 16 CDBs ?)

On Fri, Sep 5, 2014 at 9:51 AM, Peter Lieven <pl@kamp.de> wrote:
> This series adds the basics for introducing a maximum transfer length
> to the block layer. Its main purpose is currently avoiding that
> a multiwrite_merge exceeds the max_xfer_len of an attached iSCSI LUN.
> This is a required bug fix.
>
> Discussed reporting of this maximum in the SCSI Disk Inquiry Emulation
> of the Block Limits VPD is currently not added as we do not import any
> of the other limits there. This has to be addresses in a seperate series.
>
> Peter Lieven (4):
>   BlockLimits: introduce max_transfer_length
>   block: immediate cancel oversized read/write requests
>   block/iscsi: set max_transfer_length
>   block: avoid creating oversized writes in multiwrite_merge
>
>  block.c                   |   23 +++++++++++++++++++++++
>  block/iscsi.c             |   12 ++++++++++--
>  include/block/block_int.h |    3 +++
>  3 files changed, 36 insertions(+), 2 deletions(-)
>
> --
> 1.7.9.5
>