From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1addFe-0005WK-GC for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:30:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1addFZ-0003Pj-Hg for qemu-devel@nongnu.org; Wed, 09 Mar 2016 07:30:06 -0500 Sender: Paolo Bonzini References: <20160309121139.GA21975@aepfle.de> From: Paolo Bonzini Message-ID: <56E0173C.70407@redhat.com> Date: Wed, 9 Mar 2016 13:29:48 +0100 MIME-Version: 1.0 In-Reply-To: <20160309121139.GA21975@aepfle.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] bogus bdrv_check_request in bdrv_co_discard List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Olaf Hering , Kevin Wolf , Stefan Hajnoczi Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On 09/03/2016 13:11, Olaf Hering wrote: > 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. It depends on the backend. For example SCSI uses the block limits VPD page. It has a default max-unmap-size of 1 GiB, which happens to be smaller than BDRV_REQUEST_MAX_SECTORS too. It probably should range check max_unmap_size and max_io_size against BDRV_REQUEST_MAX_SECTORS, and reject anything bigger than that, though. Paolo > 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.