From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1add3r-0000EG-G7 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:17:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1add3q-0000BD-HO for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:17:55 -0500 Date: Wed, 9 Mar 2016 13:11:40 +0100 From: Olaf Hering Message-ID: <20160309121139.GA21975@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: [Qemu-devel] bogus bdrv_check_request in bdrv_co_discard List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Stefan Hajnoczi Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org What is the purpose of the bdrv_check_request() call in bdrv_co_discard? It seems a frontend cant possibly know what the limit is in the qemu-of-the-day, I found no interface to propagate BDRV_REQUEST_MAX_SECTORS into the guest. I think to handle nb_sectors > BDRV_REQUEST_MAX_SECTORS bdrv_co_discard has to split the request into smaller chunks, just as it does a few lines down in the function. Olaf