[ipxe-devel] [ipxe/ipxe] [efi] Restore the TPL to the original one (#113)

[Jarrod Johnson]

I can confirm same behavior, using bootx64.efi from esxi 7, the following produces the same behavior he reported:
#!ipxe
chain boot/efi/boot/bootx64.efi -c /path/to/boot.cfg also call efi_snp_release() of course.

> iPXE then invokes the OS kernel via StartImage(). At this point, the TPL is whatever TPL was recorded when iPXE was started, which should be TPL_APPLICATION.

Well, iPXE code may still run at this point. In fact it explicitly does for iPXE booted ESXi boot loader. efi_download.c has three functions that may be called by the loaded efi executable. At the very least they call efi_download_start. I don't know the full flow of the code, but I am wondering if efi_download_start use of intf_init or xfer_open before calling efi_snp_claim causes a RaiseTPL before efi_snp_claim stores the old TPL causing it to erroneously 'save' iPXE induced TPL_CALLBACK as the 'old' TPL? I am a bit preoccupied today, but I'd be tempted to modify efi_download_start() to call claim earlier and call efi_snp_release() on error. I'm a bit rusty and I botched even a simple change so I'm not sure.

If my naive guess happens to be in the ballpark, it doesn't explain a *seeming* improvement in our Linux boot testing, where iPXE DL protocol is not used and we also were seeing errors on kernel trying to exit boot servicing that happened *sometimes*. However this was a little fuzzier so it may not be completely accurate.



-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/113#issuecomment-651752678
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20200630/68d29623/attachment.htm>