From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation Date: Wed, 28 Oct 2009 11:54:31 +0100 Message-ID: <4AE822E7.2010108@redhat.com> References: <4AE71116.6080809@suse.de> <4AE72419.60608@redhat.com> <20091028091129.n46xqd1lww8oosc8@imap.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org To: Hannes Reinecke Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58950 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752304AbZJ1Kyi (ORCPT ); Wed, 28 Oct 2009 06:54:38 -0400 In-Reply-To: <20091028091129.n46xqd1lww8oosc8@imap.suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Hi, >>> In order to support SCSI command emulation I had to update / >>> patch up the existing SCSI disk support. This might be >>> not to everyones taste, so I'm open to alternative >>> suggestions. >>> >>> But I certainly do _not_ want to update the SCSI disk >>> emulation, as this is really quite tied to the SCSI parallel >>> interface used by the old lsi53c895a.c. >> >> --verbose please. I'd prefer to fix scsi-disk bugs and/or limitations >> instead of working around them. >> > The problem is I don't have any documentation for the LSI parallel > SCSI controller. So I don't know if and in what shape I/O is passed > down, nor anything else. [ after briefly checking the code ] Hmm. Data is passed back+forth between scsi-device and scsi-adapter using a bounce buffer per request and a amazing maze of callbacks ... That interface needs some serious rework, so we have a chance to kill the memcpy() and use iovecs. > And as the SCSI disk emulation is really > tied into the LSI parallel SCSI controller, any change in the former > is likely to break the latter. Not really. > And what with me no way of fixing it. Hence I decided on this approach. From a really quick view fixing up the data xfer code paths doesn't look too bad. Think I'll give it a try. >>> Plus it doesn't do scatter-gather list handling, >> >> Which should be fixed anyway. >> > Quite. But as I said, the LSI parallel SCSI controller is going to > suffer. Don't think so. Even if scsi-disk *supports* scatter lists, lsi isn't forced to actually use that. I think we'll need a bounce-buffer mode anyway for usb-msd because it streams the scsi data in tons of small packets over usb ... cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N36B0-0008EO-CK for qemu-devel@nongnu.org; Wed, 28 Oct 2009 06:54:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N36At-0008Br-0A for qemu-devel@nongnu.org; Wed, 28 Oct 2009 06:54:47 -0400 Received: from [199.232.76.173] (port=36222 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N36As-0008BY-3p for qemu-devel@nongnu.org; Wed, 28 Oct 2009 06:54:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10834) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N36Ar-0005IG-Cv for qemu-devel@nongnu.org; Wed, 28 Oct 2009 06:54:41 -0400 Message-ID: <4AE822E7.2010108@redhat.com> Date: Wed, 28 Oct 2009 11:54:31 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation References: <4AE71116.6080809@suse.de> <4AE72419.60608@redhat.com> <20091028091129.n46xqd1lww8oosc8@imap.suse.de> In-Reply-To: <20091028091129.n46xqd1lww8oosc8@imap.suse.de> Content-Type: text/plain; charset=UTF-8; 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: qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Hi, >>> In order to support SCSI command emulation I had to update / >>> patch up the existing SCSI disk support. This might be >>> not to everyones taste, so I'm open to alternative >>> suggestions. >>> >>> But I certainly do _not_ want to update the SCSI disk >>> emulation, as this is really quite tied to the SCSI parallel >>> interface used by the old lsi53c895a.c. >> >> --verbose please. I'd prefer to fix scsi-disk bugs and/or limitations >> instead of working around them. >> > The problem is I don't have any documentation for the LSI parallel > SCSI controller. So I don't know if and in what shape I/O is passed > down, nor anything else. [ after briefly checking the code ] Hmm. Data is passed back+forth between scsi-device and scsi-adapter using a bounce buffer per request and a amazing maze of callbacks ... That interface needs some serious rework, so we have a chance to kill the memcpy() and use iovecs. > And as the SCSI disk emulation is really > tied into the LSI parallel SCSI controller, any change in the former > is likely to break the latter. Not really. > And what with me no way of fixing it. Hence I decided on this approach. From a really quick view fixing up the data xfer code paths doesn't look too bad. Think I'll give it a try. >>> Plus it doesn't do scatter-gather list handling, >> >> Which should be fixed anyway. >> > Quite. But as I said, the LSI parallel SCSI controller is going to > suffer. Don't think so. Even if scsi-disk *supports* scatter lists, lsi isn't forced to actually use that. I think we'll need a bounce-buffer mode anyway for usb-msd because it streams the scsi data in tons of small packets over usb ... cheers, Gerd