From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRdI4-0002O3-Cd for qemu-devel@nongnu.org; Wed, 01 Jun 2011 00:44:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRdI2-0004D1-U9 for qemu-devel@nongnu.org; Wed, 01 Jun 2011 00:44:20 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:50261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRdI2-0004Co-L8 for qemu-devel@nongnu.org; Wed, 01 Jun 2011 00:44:18 -0400 Received: by yxk8 with SMTP id 8so2476415yxk.4 for ; Tue, 31 May 2011 21:44:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DE361DB.7090801@redhat.com> References: <4DD6246F.4080802@gnu.org> <20110528193321.GA32647@stefanha-thinkpad.localdomain> <4DE361DB.7090801@redhat.com> Date: Wed, 1 Jun 2011 05:44:17 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] virtio scsi host draft specification, v2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , qemu-devel On Mon, May 30, 2011 at 10:22 AM, Paolo Bonzini wrote= : > On 05/28/2011 09:33 PM, Stefan Hajnoczi wrote: >>> Requests have the following format: >>> >>> =A0 =A0 struct virtio_scsi_req_cmd { >>> =A0 =A0 =A0 =A0 u8 lun[8]; >>> =A0 =A0 =A0 =A0 u64 id; >>> =A0 =A0 =A0 =A0 u8 task_attr; >>> =A0 =A0 =A0 =A0 u8 prio; >>> =A0 =A0 =A0 =A0 u8 crn; >>> =A0 =A0 =A0 =A0 u32 num_dataout, num_datain; >> >> These fields can be discovered from the in and out counts that virtio >> provides. =A0They seem redundant to me. > > I'm not sure, perhaps in the future more variable-sized fields may be add= ed. > =A0I added a note that requests will be failed if the driver detects > inconsistencies between the actual number of buffers, and the count > specified in num_dataout/num_datain. Okay, you're right that it will be necessary if more multi-buffer data is a= dded. >> SAMr4 5.1 The Execute Command procedure call: >> "The CRN value zero shall be reserved for use as defined by the SCSI >> transport protocol." >> >> FWIW the SRP spec simply doesn't include CRN and I think we could do the >> same. =A0I don't know what it is actually used for in other transports..= . > > I wasn't sure of what would happen in the case of SCSI passthrough to > protocols that do use CRN. =A0It seems "free" to leave it in. I don't know the answer here. >>> The control receiveq is used by the device to report information on >>> logical units that are attached to it. =A0The driver should always >>> leave a few (?) buffers ready in the control receiveq. =A0The device ma= y >> >> "The driver should always leave buffers ready in the control receiveq" >> >> Also, I think it should say "the device must drop events if it finds no >> buffer ready". =A0The spec goes into detail on how to notify about dropp= ed >> events, using "must" instead of "may" seems right. > > "Must" seems too strong. =A0Dropped events are a racy event, so it is not > really possible to guve any guarantee. =A0I changed it to "will" though. Okay thanks, I was more worried about allowing the device to queue when event buffers are not available. If the dropping behavior is part of the spec then it is clear what the device implementation should do. Stefan