From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) by mx.groups.io with SMTP id smtpd.web10.47622.1585566756488033347 for ; Mon, 30 Mar 2020 04:12:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VEF/46pz; spf=pass (domain: redhat.com, ip: 216.205.24.74, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585566755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jsQoj3fsotHmeoSAlr9PovrjDDrdSnMnOAYYf5aBXfA=; b=VEF/46pzQQd76X401qyedS5mBRWnbVM/Hdxejt402tAkAo2DfrJkpCuW6JxzeSFcn6uDrp EReu0PLJ2CG7pQRlJJ8gIvN58HDEyKDu1l8U473upowrUJA3q3toig1AGvRQTBaHtVmBZH khGUxdBiQT3HyqCG8Vk0b7E4XrEGB1U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-313-UgrpdzuWMpKyWc5V5xcWSQ-1; Mon, 30 Mar 2020 07:12:19 -0400 X-MC-Unique: UgrpdzuWMpKyWc5V5xcWSQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 311F618A5500; Mon, 30 Mar 2020 11:12:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-191.ams2.redhat.com [10.36.112.191]) by smtp.corp.redhat.com (Postfix) with ESMTP id 99C7648; Mon, 30 Mar 2020 11:12:16 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 15/17] OvmfPkg/PvScsiDxe: Support sending SCSI request and receive response To: Liran Alon , devel@edk2.groups.io Cc: nikita.leshchenko@oracle.com, aaron.young@oracle.com, jordan.l.justen@intel.com, ard.biesheuvel@linaro.org References: <20200325161005.16743-1-liran.alon@oracle.com> <20200325161005.16743-16-liran.alon@oracle.com> <6f32838a-d136-050e-7a05-f817da7954a8@oracle.com> <65eb2511-e2f5-d2b5-4470-278b06a0e077@oracle.com> From: "Laszlo Ersek" Message-ID: <4781505a-9f13-12be-e763-a9d706bbe35e@redhat.com> Date: Mon, 30 Mar 2020 13:12:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <65eb2511-e2f5-d2b5-4470-278b06a0e077@oracle.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 03/27/20 23:17, Liran Alon wrote: > Furthermore, I have later found ScsiExecuteSCSICommand() in > MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c to be the one that calls the > PassThru() method. > Looking at it's "if (ScsiIoDevice->ExtScsiSupport)" branch (Which is > relevant to us), one can see it just simply executes the PassThru() > device and returns. > Examining ScsiExecuteSCSICommand() documentation specifies for > EFI_BAD_BUFFER_SIZE: >=20 > =A0 @retval EFI_BAD_BUFFER_SIZE The SCSI Request Packet was executed, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 but the entire DataBuffer could not be > transferred. > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 The actual number of bytes transferred is > returned > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 in TransferLength. See HostAdapterStatus, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 TargetStatus, SenseDataLength, and > SenseData in > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 that order for additional status information. >=20 (1) The commit that added the "ScsiIoDevice->ExtScsiSupport" branch to Scsi= ExecuteSCSICommand() was 70c94b3b6ddf ("Porting R8's PI-enabled ScsiBus dri= ver", 2007-07-02). $ git show -U100 70c94b3b6ddf At that time, the ScsiExecuteSCSICommand() function had the following docum= entation: EFI_SUCCESS - The SCSI Request Packet was sent by the host= =20 successfully, and TransferLength bytes were=20 transferred to/from DataBuffer.See=20 HostAdapterStatus, TargetStatus,=20 SenseDataLength, and SenseData in that order for additional status information. EFI_WARN_BUFFER_TOO_SMALL - The SCSI Request Packet was executed,=20 but the entire DataBuffer could not be transfe= rred. The actual number of bytes transferred is retu= rned in TransferLength. See HostAdapterStatus,=20 TargetStatus, SenseDataLength, and SenseData i= n=20 that order for additional status information. No "EFI_BAD_BUFFER_SIZE". So commit 70c94b3b6ddf was not entirely correct, because after it, the Scsi= ExecuteSCSICommand() could return EFI_BAD_BUFFER_SIZE (propagating it from = ScsiIoDevice->ExtScsiPassThru->PassThru()), but the function's documentatio= n was not updated. (At the same commit, "MdePkg/Include/Protocol/ScsiPassThruExt.h" already sp= ecified EFI_BAD_BUFFER_SIZE as "The SCSI Request Packet was not executed" -= - that had come from commit d1f950002362, "Checked in the Protocols introdu= ced in UEFI/PI.", 2007-06-19.) (2) In commit f36d6e669c97 (2007-09-20), the leading comment block on ScsiE= xecuteSCSICommand() was updated. The EFI_WARN_BUFFER_TOO_SMALL retval disap= peared, and the incorrect EFI_BAD_BUFFER_SIZE language ("The SCSI Request P= acket was executed") appeared. (Incorrect for the "EXT" passthru, anyway.) Interestingly, in this commit message, we see: 3. Correctify some return status to sync with newest Uefi Spec 2.1 However, in the UEFI 2.0 spec , EFI_BAD_BUFFER_SIZE i= s already defined as "The SCSI Request Packet was not executed". So I think it's a bug in edk2 (at least a documentation bug). Thanks Laszlo