From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR0gK-0005gf-E5 for qemu-devel@nongnu.org; Mon, 08 Sep 2014 11:16:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XR0gB-0004JM-4S for qemu-devel@nongnu.org; Mon, 08 Sep 2014 11:16:40 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:37354 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR0gA-0004Iw-QD for qemu-devel@nongnu.org; Mon, 08 Sep 2014 11:16:31 -0400 Message-ID: <540DC849.8030203@kamp.de> Date: Mon, 08 Sep 2014 17:16:25 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1409935888-18552-1-git-send-email-pl@kamp.de> <1409935888-18552-3-git-send-email-pl@kamp.de> <20140908134434.GB22582@irqsave.net> <540DB3E2.6010905@redhat.com> <540DB583.4030101@kamp.de> <540DB5EB.2070705@redhat.com> <540DBEBD.9040701@kamp.de> <540DC059.4000907@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ronnie sahlberg , Paolo Bonzini Cc: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , Kevin Wolf , qemu-devel , Stefan Hajnoczi , Max Reitz On 08.09.2014 17:13, ronnie sahlberg wrote: > On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini wrote: >> Il 08/09/2014 16:35, Peter Lieven ha scritto: >>>>>> messages. :) >>>>> So you would not throw an error msg here? >>>> No, though a trace could be useful. >>> Is there a howto somewhere how to implement that? >> Try commit 4ac4458076e1aaf3b01a6361154117df20e22215. >> >>> Whats your opinion changed the max_xfer_len to 0xffff regardsless >>> of use_16_for_rw in iSCSI? >> If you implemented request splitting in the block layer, it would be >> okay to force max_xfer_len to 0xffff. > I think it should be OK if that is a different series. This only > affects the iSCSI transport since it is the only transport so far to > record or report a max transfer length. > If a guest generates these big requests(i.e. not multiwrite) we > already fail them due to the READ10 limitations. We would just fail > the request at a different layer in the stack with these patches. > > > What I would like to see would also be to report these limitations to > the guest itself to prevent it from generating too large I/Os. > I am willing to do that part once the initial max_xfer_len ones are finished. Yes, I also think this approach is straightforward. We should avoid big requests at the beginning and not fix them at the end. I had a look it shouldn't be too hard. There are default values for virtio-scsi HD inquiry emulation which are set if no cmdline values are specified. It should be possible to feed them from bs->bl if set. Peter