From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFpYv-0006I5-Vh for qemu-devel@nongnu.org; Wed, 02 Dec 2009 08:48:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFpYq-0006BB-Lu for qemu-devel@nongnu.org; Wed, 02 Dec 2009 08:48:08 -0500 Received: from [199.232.76.173] (port=58132 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFpYo-0006AL-TQ for qemu-devel@nongnu.org; Wed, 02 Dec 2009 08:48:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30170) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFpYo-0004CJ-M6 for qemu-devel@nongnu.org; Wed, 02 Dec 2009 08:48:02 -0500 Message-ID: <4B167004.509@redhat.com> Date: Wed, 02 Dec 2009 14:47:48 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <200911161853.34668.paul@codesourcery.com> <4B0BCAA1.3090400@redhat.com> <200911241351.03650.paul@codesourcery.com> <4B0D5D36.6080100@redhat.com> <4B0E2EC8.7040309@suse.de> <4B0E3B90.5080001@redhat.com> <4B0E5EFD.6060701@suse.de> <4B0E60AF.9000508@redhat.com> <4B0E6496.1060203@suse.de> <4B0E8EF6.2080106@redhat.com> <4B0E9036.2070400@suse.de> <4B0E92B1.10903@redhat.com> <4B0EA3C2.2020007@suse.de> <4B0FB34A.50501@redhat.com> In-Reply-To: <4B0FB34A.50501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hannes Reinecke Cc: Paul Brook , qemu-devel@nongnu.org On 11/27/09 12:08, Gerd Hoffmann wrote: > On 11/26/09 16:50, Hannes Reinecke wrote: >> So indeed, this approach would only work if we signal some sense code >> back to the host. >> I, OTOH, don't have any qualms with returning HARDWARE_ERROR, >> 0x26/0x08(TOO MANY SEGMENT DESCRIPTORS) resp 0x26h/0x0B (INLINE DATA >> LENGTH EXCEEDED). >> Feels only fair to notify the guest it has done something wrong. > > Also set the info field which linux uses to figure how many sectors it > actually got. Hmm. Well. Seems to work out at least for linux, i.e. it figures it got a bunch of sectors and tries to continue. Linux logs an I/O error. Also I didn't try other guests (yet). Using that as a way to limit scsi-disk request sizes probably isn't a good idea. For scsi-generic that would be a improvement over the current situation though. cheers, Gerd