On 03/19/21 18:41, Andrew Fish wrote:
CR2 points the 1st level of the page tables. Those entries point to other page tables, so you kind of have to walk it by hand.
I think that's a typo: it should be CR3.
But, I agree -- you can use QEMU monitor commands to read RAM words, and
walk the page tables manually. (I figured I could help with this, but I
couldn't reproduce the issue locally. I used the manual Recovery entry
-- click "Reboot" with Shift held down. For me the Windows VM just
entered recovery fine.)
On Mar 19, 2021, at 9:56 AM, Annie Li <firstname.lastname@example.org> wrote:
In DumpCpuContext function in ArchExceptionHandler.c, the exception details are gotten from either "SystemContextX64->ExceptionData" or "SystemContextX64.xxx". I am wondering how I can dump the page info there? Are there some related info that can be retrieved from CR2? can you enlighten me a little bit?
From: Yao, Jiewen [mailto:email@example.com]
Sent: Thursday, March 18, 2021 8:37 PM
To: firstname.lastname@example.org; Annie Li <email@example.com>; Laszlo Ersek <firstname.lastname@example.org>
Cc: Wang, Jian J <email@example.com>; Andrew Fish <firstname.lastname@example.org>; Aaron Young <email@example.com>; Yao, Jiewen <firstname.lastname@example.org>
Subject: RE: [edk2-discuss] Windows guest fails to boot into recovery mode due to commit 5267926
I added some of my thought in the Bugzilla. - https://urldefense.com/v3/__https://bugzilla.tianocore.org/show_bug.cgi?id=3269__;!!GqivPVa7Brio!JMob8PcNWJxj_RZSIWy7iwhqFFhIYSwtnR_8i0X6V-UzBkycx-iObkffqGNBrw$
If you can dump paging structure info for further analysis, we can help to check.
From: email@example.com <firstname.lastname@example.org> On Behalf Of
Sent: Friday, March 19, 2021 3:27 AM
To: Laszlo Ersek <email@example.com>; firstname.lastname@example.org
Cc: Wang, Jian J <email@example.com>; Andrew Fish
<firstname.lastname@example.org>; Aaron Young <email@example.com>
Subject: Re: [edk2-discuss] Windows guest fails to boot into recovery
mode due to commit 5267926
In my previous email, the exception is reproduced with pretty old code
base from where I started bisecting the comments. This time I
reproduce this issue with the code of branch 'stable/202011' of
upstream. All the log I am collecting is from this code base(75ab038).
Since the overall size of all log is pretty big, I'll attach all the
data you required in to this bug(https://urldefense.com/v3/__https://bugzilla.tianocore.org/show_bug.cgi?id=3269__;!!GqivPVa7Brio!JMob8PcNWJxj_RZSIWy7iwhqFFhIYSwtnR_8i0X6V-UzBkycx-iObkffqGNBrw$ ).
I dump the register by qmp-regdump, and the result(regdump) is
uploaded into this bug. If this log doesn't suffice, can you please suggest the way you prefer?
The objdump is uploaded, as well as the details of page fault
exception, please check the details there.
From: Laszlo Ersek [mailto:firstname.lastname@example.org]
Sent: Thursday, March 18, 2021 9:23 AM
To: Annie Li <email@example.com>; firstname.lastname@example.org
Cc: email@example.com; Andrew Fish <firstname.lastname@example.org>
Subject: Re: Windows guest fails to boot into recovery mode due to
On 03/18/21 02:48, Annie Li wrote:
I ran into a windows booting failure issue(a page fault exception),
and narrow down it to the following patch,
MdeModulePkg/DxeIpl: support more NX related PCDs
This issue always happens after QMP is terminated by <ctrl-C> twice,
should boot into recovery mode in this round, and this is due to the
1. Boot Windows VM up, and <ctrl-C> to exit the QMP
2. Repeat 1
3. Boot Windows VM, and this page fault issue happens. (Note: Windows
previous two consecutive boot failure, see
due to the patch above(5267926). I modified the return value to
During above 3 windows booting procedures, the value of following
variables are always the same, PcdSetNxForStack 0
PcdDxeNxMemoryProtectionPolicy 0 PcdImageProtectionPolicy 2
However, Windows guest fails to boot up into recovery mode in the
"(PcdGetBool (PcdSetNxForStack)" in function "IsEnableNonExecNeeded"
in MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c, this page fault
issue is gone with this change. The patch(5267926) is for fixing bug
sjSaIZXk_W_MusXNUlQBxGqsJBTLSxdsog$ , where the comments show
PcdImageProtectionPolicy needs also to enable NXE. But this does cause
the page fault exception in this scenario, any suggestion?
The page fault exception is pasted here,
!!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!!
ExceptionData - 0000000000000009 I:0 R:1 U:0 W:0 P:1 PK:0 SS:0
SGX:0 RIP - 000000003E0A7C75, CS - 0000000000000038, RFLAGS -
0000000000010202 RAX - 8000000000000003, RCX - 0000000000000001,
- 0000000001040001 RBX - 0000000000000001, RSP - 00000000001A6AA0,
RBP - 0000000001040001 RSI - 000000003F2E2010, RDI - 0000000000000001
R8 - 0000000000000000, R9 - 000000003E0AEC90, R10 - 0000FFFFFFFFF000
R11 - 00000000001A6E90, R12 - 0000000000000000, R13 -
R14 - 00000000001A6B28, R15 - 00000000001AB000
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 000000003F2E2010, CR3 -
CR4 - 0000000000040668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 -
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 -
0000000000000400 GDTR - 000000003F1EE698 0000000000000047, LDTR -
IDTR - 000000003ECCA018 0000000000000FFF, TR - 00000000000000001.4.3/Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Universal/Console/T
FXSAVE_STATE - 00000000001A6700
!!!! Find image based on IP(0x3E0A7C75) /builddir/build/BUILD/edk2-
(ImageBase=000000003E0A5000, EntryPoint=000000003E0A86E8) !!!!
In addition to what Andrew said, I suggest the following:
(1) Please rebuild OVMF *locally*, using the same edk2 tree, and the
same toolchain, and the same "build" flags.
(2) Reproduce the issue, capture the register dump.
(3) Run the following command:
objdump -f -S
The point of this exercise is to reproduce the issue with such an OVMF
build for which you have a matching "TerminalDxe.debug" file. Once you
do that, you can run "objdump" on the ".debug" file, and get a
disassembly of the TerminalDxe driver, inter-leaved with the C language source code.
Then, we can do two things:
- we can verify whether (EntryPoint - ImageBase), from the register
dump, matches the (relative) "start address" that "objdump -f"
- we can take the crash offset (RIP - ImageBase), from the register
dump, and use that offset into the "objdump -S" disassembly, to narrow
down what the terminal driver may have been doing to trigger the crash.
It's not necessarily the terminal driver's fault that encounter a
crash, but knowing what TerminalDxe was up to, might shed light on the
actual reason. It's of course also possible that TerminalDxe *is* at fault. We'll see.
If possible, please post:
- your precise edk2 version (if you have local patches, it would be
best to reproduce with an upstream-only tree),
- your full firmware log (feel free to compress it),
- the register dump from serial,
- the objdump (disassembly) output (feel free to compress it).