Hi all,
So far, I've considered:
- DxePcdLib could try calling the protocol after exit-BS, which is guaranteed to fail (then page fault). However, I've checked the disassembly and it's not used on resume flow. This is fine.
- DebugLibSerialPort is used for this module, because RSC's serial port handler is unregistered at exit-BS. This should now be fine.
Some (potentially) plausible architectural issues:
- Page tables are used in long mode. Maybe I could verify these are sane by looking up the structure and printing each entry's fields, but they are probably fine.
- Maybe BootScriptStackSize is too small? I sort of doubt it from looking at the disassembly. Also, even if the stack overflows, I'd expect the earlier debug prints to succeed.
- Maybe my added debug print in S3BootScriptExecutorEntryFunction() is a problem? However, it's the IDTR that's written, not the GDTR. I'd expect that to only be an issue if an interrupt is fired. Also, SmmRestoreCpu() does the same. As I understand, normally there is an enormous difference between DXE and
SMM, because SMM has some resume state in some CPU MSRs (etc), but I think
here PiSmmCpuDxeSmm is being entered as if it were mere 64-bit code,
like DXE.