On 01/06/2016 14:26, Laszlo Ersek wrote: > 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: > > 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?
Yes, it is. If the PT address is constant, perhaps you can attach gdb to QEMU and set a hardware watchpoint on the PTE? Paolo > 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
