From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR02v-0008Sg-LX for qemu-devel@nongnu.org; Mon, 08 Sep 2014 10:36:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XR02m-00071X-Lb for qemu-devel@nongnu.org; Mon, 08 Sep 2014 10:35:57 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:51766 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR02m-00071P-BR for qemu-devel@nongnu.org; Mon, 08 Sep 2014 10:35:48 -0400 Message-ID: <540DBEBD.9040701@kamp.de> Date: Mon, 08 Sep 2014 16:35:41 +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> In-Reply-To: <540DB5EB.2070705@redhat.com> Content-Type: text/plain; charset=windows-1252; 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: Paolo Bonzini , =?windows-1252?Q?Beno=EEt_Cane?= =?windows-1252?Q?t?= Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com, mreitz@redhat.com On 08.09.2014 15:58, Paolo Bonzini wrote: > Il 08/09/2014 15:56, Peter Lieven ha scritto: >>>> Look like you are changing the coroutine version. >>>> >>>> Some hardware like virtio-blk uses the AIO version of read and writes. >>>> What would happen if all the block drivers down the chain are AIO >>>> enabled ? >>> The AIO version still goes through bdrv_co_do_readv/writev. >>> >>> However, error_report is not something you can use for guest-accessible >>> error messages, unless you want your logs to fill up with error >>> 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? Then I would send a v2 if there are no other complaints. Whats your opinion changed the max_xfer_len to 0xffff regardsless of use_16_for_rw in iSCSI? Peter