From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAR60-0007GB-Gl for qemu-devel@nongnu.org; Tue, 17 Nov 2009 11:40:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAR5v-0007B5-Ai for qemu-devel@nongnu.org; Tue, 17 Nov 2009 11:39:59 -0500 Received: from [199.232.76.173] (port=53168 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAR5v-0007Au-37 for qemu-devel@nongnu.org; Tue, 17 Nov 2009 11:39:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50197) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NAR5u-00017t-K5 for qemu-devel@nongnu.org; Tue, 17 Nov 2009 11:39:54 -0500 Message-ID: <4B02D1CD.7040207@redhat.com> Date: Tue, 17 Nov 2009 17:39:41 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] megasas: LSI MegaRAID SAS HBA emulation References: <20091112114849.E783838DC3@ochil.suse.de> <4B02796E.4020504@redhat.com> <4B028048.1030403@suse.de> In-Reply-To: <4B028048.1030403@suse.de> 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: qemu-devel@nongnu.org On 11/17/09 11:51, Hannes Reinecke wrote: > Grand. Meanwhile I've dug up some more register definitions, > so I'll doing some more updates to the driver. Feel free to send updates (both incremental and replacement are fine). > Meanwhile I've stumbled across another issue: > The megasas HBA insists on returning some data like inquiry > or VPD pages during init/configuration. > > I can't really use the normal command completion here, > as eg on megasas configuration command requires me > to issue several requests to the underlying device. Well, you can, but it probably isn't very convenient ... Easy way out would be calling qemu_aio_wait(), when it returns you can be sure the request is finished (and the completion callback was called). You probably have to flag the request as being special somewhere in req->hba_private so your completion callback will not apply the usual processing. Calling qemu_aio_wait() is only needed if there is actually something in flight asynchronously. req->status is initialized to -1 and set to a status code on completion, so you can use that to figure whenever the request is still being processed. All commands emulated by scsi-disk will complete instantly, i.e. the completion callback will be called before scsi_req_{buf,sgl} returns. Only with scsi-generic you'll find INQUIRY being processed really asynchronously. cheers, Gerd