From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 18 Jul 2019 14:10:37 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 114D230A7C5E; Thu, 18 Jul 2019 21:10:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-25.ams2.redhat.com [10.36.116.25]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7B3BC1018A0D; Thu, 18 Jul 2019 21:10:35 +0000 (UTC) Subject: Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices To: Ravi Kumar Siadri , michael.d.kinney@intel.com, Leif Lindholm , "Wu, Hao A" , "Cetola, Stephano" Cc: "devel@edk2.groups.io" References: <15109.1560169952219160072@groups.io> <20b41687-a450-b81e-2393-96549100b13d@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 18 Jul 2019 23:10:34 +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: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Thu, 18 Jul 2019 21:10:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/18/19 18:02, Ravi Kumar Siadri wrote: > Hi Laszlo Ersek / Hao Wu, > > I have gone through the Guide, i can see some points which are not > very clear.. > > [...] Perhaps some examples will help. In advance, I should mention a few things: - This is just my interpretation of the spec, and of the guide. - In my last email, the VenMsg suggestion was wrong. The device paths for the physical channel(s) are built by appending Ctrl(n) -- "controller" -- hardware device path nodes, and not VenMsg() nodes. - "Logical" means "channel with abstract devices, suitable for data access & booting", "Physical" means "channel with physical devices, used for diagnostics". A channel may be *both*, if each device on it is both physical and logical simultaneously -- that is, it can be used for data access / booting, and for low-level diagnostics. So, the examples: (A) non-RAID HBA * Summary: Handle#1: PciRoot(0x0)/Pci(0x1,0x0) -- channel where each device is (L + P) Handle#2: PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x1,0x0) -- disk that is (L + P) * Details: Handle#1: - device path: PciRoot(0x0)/Pci(0x1,0x0) - handle created by PciBusDxe [= platform firmware] - device path protocol installed by PciBusDxe - PciIo protocol installed by PciBusDxe - ExtScsiPassThru protocol installed by the SCSI HBA driver, through consuming PciIo - Logical bit set in ExtScsiPassThru: meaning that devices enumerated on this channel can be used for data access & booting - Physical bit set in ExtScsiPassThru: meaning that devices enumerated on this channel can be sent diagnostic commands Handle#2: - device path: PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x1,0x0) - handle created by ScsiBusDxe [= platform firmware] - device path protocol installed by ScsiBusDxe (here: Target=1, Lun=0) - ScsiIo protocol installed by ScsiBusDxe [= platform firmware], through consuming ExtScsiPassThru on Handle#1 - BlockIo protocol installed by ScsiDiskDxe [= platform firmware], through consuming ScsiIo on the same handle (= Handle#2) (B) RAID HBA * Summary: Handle#1: PciRoot(0x0)/Pci(0x1,0x0) -- logical channel Handle#2: PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x1,0x0) -- logical disk Handle#3: PciRoot(0x0)/Pci(0x1,0x0)/Ctrl(0x0) -- physical channel Handle#4: PciRoot(0x0)/Pci(0x1,0x0)/Ctrl(0x0)/Scsi(0x4,0x0) -- physical disk #0 Handle#5 PciRoot(0x0)/Pci(0x1,0x0)/Ctrl(0x0)/Scsi(0x4,0x1) -- physical disk #1 * Details: Handle#1: - The same as Handle#1 from (A), except the Physical bit is clear in the ExtScsiPassThru protocol instance. - This handle stands for the logical channel. Handle#2: - The same as Handle#2 from (A). - This handle stands for the logical disk. Handle#3: - Device path: PciRoot(0x0)/Pci(0x1,0x0)/Ctrl(0x0). - Handle created by the SCSI HBA driver. - Device path installed by the SCSI HBA driver. - ExtScsiPassThru protocol installed by the SCSI HBA driver, through consuming PciIo on Handle#1. - Logical bit is clear in ExtScsiPassThru. - Physical bit is set in ExtScsiPassThru. - This handle stands for the physical channel. Handle#4: - Device path: PciRoot(0x0)/Pci(0x1,0x0)/Ctrl(0x0)/Scsi(0x4,0x0) - Handle created by ScsiBusDxe [= platform firmware]. - Device path protocol installed by ScsiBusDxe (here: Target=4, Lun=0). - ScsiIo protocol installed by ScsiBusDxe [= platform firmware], through consuming ExtScsiPassThru on Handle#3. - BlockIo protocol is *NOT* installed by ScsiDiskDxe [= platform firmware], due to the Logical bit being clear in ExtScsiPassThru on Handle#3. - This handle stands for the first physical disk in the array. Handle#5: - Same as Handle#4, with the following differences: - Device path: PciRoot(0x0)/Pci(0x1,0x0)/Ctrl(0x0)/Scsi(0x4,0x1). - This handle stands for the second physical disk in the array. Hope this helps, Laszlo