From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: solarflare.com, ip: 148.163.129.52, mailfrom: tpilar@solarflare.com) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by groups.io with SMTP; Wed, 22 May 2019 03:41:00 -0700 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id AEA64A8008A; Wed, 22 May 2019 10:40:59 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 22 May 2019 03:40:56 -0700 Subject: Re: [edk2-devel] iSCSI and iBFT To: Laszlo Ersek , Devel EDK2 References: <3644c44636fb4fe5b719128ec1443b4c@ukex01.SolarFlarecom.com> <1c6545291d0f460fac20abf2187a551c@ukex01.SolarFlarecom.com> From: "Tomas Pilar (tpilar)" Message-ID: <29d7e6a4-667a-7929-f4e3-96303ed0d39d@solarflare.com> Date: Wed, 22 May 2019 11:40:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24630.004 X-TM-AS-Result: No-19.946200-4.000000-10 X-TMASE-MatchedRID: 0lhM5bBmjEMH9MoYRDEfRYph1hAtvKZNMU2PxRDxHoKynk7TnYzMusUp xiubXbLIBkvBzrLqRS5bgbSHcYKLSV/J2pbTBABMF59cj9SkLeIIPkMcjqKWc39nRLJB1yYQIZR vYk3GLWp0FFkhhO3pjnK1PYJfbxc/wit0Z/2kiE1fYa9W9Ojitd1hWsVVuzNoHWtVZN0asTgoo3 x4kjavu6NJSlEpbGuMt50ul+9yGQPBivhaKvfhKLW7+o2OTMRclSphlGf1p5EqAZlo5C3Li8OLW oD10Uccf5wASl18s5ORV/zOlZpEXVDqf+tE0BQqzNY33yIEF4ZwbyuQg4BU6WjF+0h1NhXWSwjG LfgtslIqAGo1ZYOAY0RMkiC2EpePZ9cXdEbiq4D1lJyvCKVZlAeCHewokHM/CySgZBXFfsTCaBA 5v6nrh83mpvmUzywFnCacOL7CaYlZhsLGSVfWrpN65fjGjYMQMwMfB2KMdIexW4YXFsTUDtmeXd nOraZ2AAyWhgDMq7Hxuk24O6/8+WguyKTRS/AUY1bQMCMvmn4xdQUCoUD0KLmivI8gChuwxHwB3 1UIrUBtr+gF/mvwINjt0uOE0gQSUQDMsL5x9LKEeJva4+0wXZ4oEP/S42Q2uIuOQRFsnGjZznXq u/Oqu0f8idezZmLAu6MuGW0j1Ml+lsIJCWnGaHV7tdtvoibaYtVSPQ1H7Lw1m7JMTTmx2aPFjJE Fr+olA9Mriq0CDAiBrDV+XoP2jjM5SNDnT9yzfwO+RRpsStUqtq5d3cxkNQwWxr7XDKH8hcPtGA CpbMJRq/DeVTD3KWbV3eMXrVFkazMsA7zUReXr2jD7Zor7MQ== X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--19.946200-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24630.004 X-MDID: 1558521660-zi2ajATDLDdT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Yeah, I just AllocateCopyPool the static struct on heap for each device. I can honestly see how one would assume that a protocol instance would never be installed on more than one handle, same as I assumed that using a statically allocated struct containing nothing but boilerplate info would also be fine. The whole NII and UNDI drivers vs. SNP drivers compatibility across OEMs/IBVs and IHVs is a painful trash fire and this is just the last problem in a very long line of annoyances. On 22/05/2019 11:19, Laszlo Ersek wrote: > On 05/22/19 11:55, Tomas Pilar wrote: >> iPXE identifies the device it was pxe booted from by searching parents of the LoadedImage which support SNP and NII and uses the address of the installed NII and SNP as a discriminant to see if a device is in fact the one it was pxe booted from. This convoluted process is done to shoehorn chainload drivers into the ipxe driver api. >> >> Then it will chainload NII or SNP drivers on all devices if they pass the above check. My driver used a global static NII struct and installed that as NII on all ports so ipxe then tried to bind its NIIONLY driver on all ports on the adapter, not just the one it was pxebooted with. Thus it kicked off the network stack including the iSCSI connection on the second port even though it was pxe booted into using the first port. >> >> Ugh. > Thanks for the description! > > What is the solution to the problem? Per-port NII structs? (I don't have > any experience with EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL.) > > Thanks > Laszlo > > > >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek >> Sent: 21 May 2019 20:48 >> To: Devel EDK2 ; Tomas Pilar >> Subject: Re: [edk2-devel] iSCSI and iBFT >> >> On 05/21/19 16:54, Tomas Pilar (tpilar) wrote: >>> I am going to commit the cardinal sin of online dev support. >> heh :) >> >>> 'Never mind, found the problem' >> What was it? >> >> I didn't ignore your original email -- I looked at iPXE briefly, but couldn't blame anything at once, and then I quickly ran out of steam. >> There wasn't anything I could have added to the thread. >> >> Thanks, >> Laszlo >> >>> From: Tomas Pilar >>> Sent: 20 May 2019 16:57 >>> To: 'devel@edk2.groups.io' >>> Subject: iSCSI and iBFT >>> >>> Hi, >>> >>> I have a bit of an esoteric problem. When I configure the software iscsi intiator that is part of EDK2 platform network stack, the platform network stack with install iBFT table into the ACPI tables so that the configuration can be picked up by further boot loaders and the OS. So far so good. >>> >>> Problem: When I PXE boot into iPXE using my adapter, exit back into boot manager, the iBFT has disappeared. Alternatively, if I use iPXE to then boot WDS, the software initiator in WinPE won't find the iBFT table and therefore won't hook the network drive. >>> >>> Observations: >>> * When I boot into UEFI shell on disk and exit back into boot manager, the iBFT is preserved. >>> >>> * When I PXE boot into UEFI shell and exit, the iBFT is preserved. >>> >>> * When I boot into iPXE on disk and exit, the iBFT is preserved. >>> >>> * When I use a different adapter (Intel) to pxe boot into iBFT and exit back to boot manager, the iBFT has moved from the penultimate position to the last position in the ACPI tables. Almost as if something uninstalled the iBFT and reinstalled it. >>> >>> Any ideas? >>> >>> Cheers >>> Tom >>> >>> >>> >>> >> >> >>