From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSOwc-0002hB-Kr for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:23:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSOwO-00068y-VU for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:23:14 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:48150 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSOwO-00068O-Le for qemu-devel@nongnu.org; Fri, 12 Sep 2014 07:23:00 -0400 From: Peter Lieven Date: Fri, 12 Sep 2014 13:21:48 +0200 Message-Id: <1410520912-7557-1-git-send-email-pl@kamp.de> In-Reply-To: References: Subject: [Qemu-devel] [PATCHv2 0/4] introduce max_transfer_length List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, benoit.canet@irqsave.net, stefanha@redhat.com, Peter Lieven , mreitz@redhat.com, ronniesahlberg@gmail.com, pbonzini@redhat.com 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. v1->v2: do not throw errors but generate trace events in Patch 2 [Paolo] Peter Lieven (4): BlockLimits: introduce max_transfer_length block: immediately 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 +++ trace-events | 2 ++ 4 files changed, 38 insertions(+), 2 deletions(-) -- 1.7.9.5