iSCSI and iBFT

iSCSI and iBFT

[Tomas Pilar (tpilar)]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

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
The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.

[-- Attachment #2: Type: text/html, Size: 4286 bytes --]

Re: iSCSI and iBFT

[Tomas Pilar (tpilar)]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

I am going to commit the cardinal sin of online dev support.

'Never mind, found the problem'

From: Tomas Pilar
Sent: 20 May 2019 16:57
To: 'devel@edk2.groups.io' <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

[-- Attachment #2: Type: text/html, Size: 4832 bytes --]

Re: [edk2-devel] iSCSI and iBFT

[Laszlo Ersek]

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' <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
> 
> 
> 
> 

Re: [edk2-devel] iSCSI and iBFT

[Tomas Pilar (tpilar)]

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.

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: 21 May 2019 20:48
To: Devel EDK2 <devel@edk2.groups.io>; Tomas Pilar <tpilar@solarflare.com>
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' <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
> 
> 
> 
> 

Re: [edk2-devel] iSCSI and iBFT

[Laszlo Ersek]

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 <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: 21 May 2019 20:48
> To: Devel EDK2 <devel@edk2.groups.io>; Tomas Pilar <tpilar@solarflare.com>
> 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' <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
>>
>>
>>
>>
> 
> 
> 
> 

Re: [edk2-devel] iSCSI and iBFT

[Tomas Pilar (tpilar)]

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. </rant>

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 <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
>> Sent: 21 May 2019 20:48
>> To: Devel EDK2 <devel@edk2.groups.io>; Tomas Pilar <tpilar@solarflare.com>
>> 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' <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
>>>
>>>
>>>
>>>
>>
>> 
>>

Re: [edk2-devel] iSCSI and iBFT

[Michael Brown]

On 22/05/2019 11:40, Tomas Pilar (tpilar) wrote:
> 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. </rant>

Thanks for writing up the end result.  I can't immediately see any more 
viable way for iPXE to determine the NII corresponding to the user's 
concept of "the NIC from which I booted", but I'm open to suggestions.

Thanks again,

Michael

Re: [edk2-devel] iSCSI and iBFT

[Tomas Pilar (tpilar)]

I was mostly puzzled by the double step. First find a parent device to LoadedImage that support NII. Rather than using that device we will scan all devices to see if any of them has the same NII protocol and if so we use that one. I am not sure there is any advantage compared to just using the original parent device?

In either way, the device path search using NII is fairly ingenious!

On 22/05/2019 23:26, Michael Brown wrote:
> On 22/05/2019 11:40, Tomas Pilar (tpilar) wrote:
>> 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. </rant>
>
> Thanks for writing up the end result.  I can't immediately see any more viable way for iPXE to determine the NII corresponding to the user's concept of "the NIC from which I booted", but I'm open to suggestions.
>
> Thanks again,
>
> Michael
>
> 
>

Re: [edk2-devel] iSCSI and iBFT

[Michael Brown]

On 23/05/2019 10:46, Tomas Pilar (tpilar) wrote:
> I was mostly puzzled by the double step. First find a parent device to LoadedImage that support NII. Rather than using that device we will scan all devices to see if any of them has the same NII protocol and if so we use that one. I am not sure there is any advantage compared to just using the original parent device?

The problem is that we may need to attach to a parent of that original 
parent device.  The relevant commit in iPXE is:

   http://git.ipxe.org/ipxe.git/commitdiff/4c5b7945c

[efi] Use the SNP protocol instance to match the SNP chainloading device

Some systems will install a child of the SNP device and use this as
our loaded image's device handle, duplicating the installation of the
underlying SNP protocol onto the child device handle.  On such
systems, we want to end up driving the parent device (and
disconnecting any other drivers, such as MNP, which may be attached to
the parent device).

Fix by recording the SNP protocol instance at initialisation time, and
using this to match against device handles (rather than simply
comparing the handles themselves).



That commit predates the iPXE NII/UNDI driver and so refers only to SNP, 
but the same principle is applied for NII.

Michael