From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHYxX-0000HL-3d for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:28:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHYxS-00009n-T7 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:28:42 -0500 Received: from [199.232.76.173] (port=33119 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHYxS-00009e-Ov for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:28:38 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54396 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHYxS-0003dL-ER for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:28:38 -0500 Message-ID: <4B1CBCB0.10605@suse.de> Date: Mon, 07 Dec 2009 09:28:32 +0100 From: Hannes Reinecke 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> <4B167004.509@redhat.com> In-Reply-To: <4B167004.509@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Paul Brook , qemu-devel@nongnu.org Gerd Hoffmann wrote: > 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. >=20 > 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). >=20 > 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. >=20 Yes, quite. But for scsi-disk we could always fallback to using bounce-buffers, could we not? Provide we get a detailed enough error code, but this could be arranged methinks. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: Markus Rex, HRB 16746 (AG N=FCrnberg)