On 06/01/16 13:30, Paolo Bonzini wrote: > > > On 01/06/2016 12:50, Laszlo Ersek wrote: >> In other words, the fault is raised and delivered (== the handler is >> entered) entirely within non-root operation, inside the VM. I find >> this amazing. (Amazingly annoying.) > > It is indeed. You can try using ept=0 to see the page faults.
Given that it reproduces with TCG, I added the following option to the QEMU command line: -d int,pcall It absolutely spams the output, but the last two state dumps preceding the fault are: > SMM: enter > RAX=0000000000000000 RBX=000000007de158c0 RCX=00000000000000b2 > RDX=00000000000000b2 > RSI=000000007f76c440 RDI=0000000000000c99 RBP=000000007f76c3a0 > RSP=000000007f76c380 > R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000064 > R11=0000000000000040 > R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 > R15=0000000000000000 > RIP=000000007f6ae479 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > CS =0038 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-] > SS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > DS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] > GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] > LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT > TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy > GDT= 000000007f6edf18 00000047 > IDT= 000000007ef76018 00000fff > CR0=80000033 CR2=0000000000000000 CR3=000000007f70b000 CR4=00000668 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > CCS=0000000000000000 CCD=0000000000000000 CCO=SUBQ > EFER=0000000000000500 > > check_exception old: 0xffffffff new 0xe > 7918: v=0e e=0009 i=0 cpl=0 IP=0038:000000007feee48d pc=000000007feee48d > SP=0020:000000007ffa9760 CR2=00000000ffe00020 > RAX=00000000ffe00020 RBX=0000000000001fc4 RCX=0000000000000402 > RDX=0000000000000402 > RSI=000000007ff75180 RDI=000000007feb4034 RBP=000000007ffa9800 > RSP=000000007ffa9760 > R8 =0000000000000001 R9 =0000000000000000 R10=00000000ffffffff > R11=0000000000000000 > R12=0000000000000c4d R13=0000000000000000 R14=0000000000000000 > R15=0000000000000000 > RIP=000000007feee48d RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=1 HLT=0 > ES =0020 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > CS =0038 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA] > SS =0020 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > DS =0020 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > FS =0020 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > GS =0020 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] > LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT > TR =0040 000000007ff99050 00000067 00008900 DPL=0 TSS64-avl > GDT= 000000007ff99000 0000004f > IDT= 000000007ffcf10c 000001ff > CR0=80010033 CR2=00000000ffe00020 CR3=000000007ff9a000 CR4=00000668 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > CCS=0000000000000001 CCD=0000000000000000 CCO=LOGICB > EFER=0000000000000d00 RIP (7feee48d) and CR2 (ffe00020) are consistent with the guest's own report: > ~SmiPFHandler: PFAddress=0xFFE00020 Rip=0x7FEEE48D > PageTable = 7FFA7000, PTIndex = 1FF, PageTable[PTIndex] = 7FFF31BD > New page table overlapped with old page table! > ASSERT .../UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c(618): ((BOOLEAN)(0==1)) Is this useful information? Error code 0xe is EXCP0E_PAGE, right? Maybe I can investigate it a bit more. Hm, according to <http://wiki.osdev.org/Exceptions#Page_Fault> -- hey, why consult the Intel SDM when you can read wiki pages on the net, right? :) --, and assuming that "e=0009" is the error code, it seems we have: - Present (bit #0, value 1): "When set, the page fault was caused by a page-protection violation. When not set, it was caused by a non-present page." - Reserved write (bit #3, value 8): "When set, the page fault was caused by reading a 1 in a reserved field." Does this imply that the (various level) page table entries that cover the varstore pflash chip get corrupted at some point? (How else would those "reserved bits" get set?) This would be consistent with Jeff's statement > PageTable[PTIndex] = 7FFF2251 is not one valid page entry. > Usually, we encountered the similar issue due to SMM page table room > was crashed. (NB: this is the only invocation of SmiPFHandler() that I see in the OVMF log. Also, in this case, the PTE is 7FFF31BD.) Thanks, Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
