On 08/07/15 00:38, Laszlo Ersek wrote: > On 08/06/15 16:55, Paolo Bonzini wrote: >> >> >> On 06/08/2015 16:31, Laszlo Ersek wrote: >>>> kvm_cpuid: func 80000001 rax 6e8 rbx 0 rcx 0 rdx 100000 >>>> kvm_enter_smm: vcpu 0: leaving SMM, smbase 0x7ffc0000 >>>> kvm_entry: vcpu 0 >>>> kvm_exit: reason TRIPLE_FAULT rip 0x7ffdb6b2 info 0 0 >>>> kvm_userspace_exit: reason KVM_EXIT_SHUTDOWN (8) >> >> Can you provide a trace with both kvm and kvmmmu events enabled? > > The "trace-cmd report" command printed the following to stderr: > > trace-cmd: No such file or directory > function is_writable_pte not defined > > Not sure how serious that is; FWIW it did produce a human readable > report. Please find it at > <http://people.redhat.com/~lersek/smbase_reloc_triple_fault/trace.txt.xz>. > > The trace covers the full lifetime of the guest (I started tracing > before launching the guest, and I passed -no-reboot to qemu, so when the > guest crashed, QEMU exited.) > > This was on 3.10.0-299.el7.x86_64. I repeated the test with EPT off. The guest doesn't crash this way, it spins in a busy loop. qemu-system-i38-32767 [002] 55142.911133: kvm_emulate_insn: 0:7ffd790b: 0f aa qemu-system-i38-32767 [002] 55142.911139: kvm_cpuid: func 80000001 rax 6e8 rbx 0 rcx 0 rdx 100000 qemu-system-i38-32767 [002] 55142.911148: kvm_enter_smm: vcpu 0: leaving SMM, smbase 0x7ffc0000 qemu-system-i38-32767 [002] 55142.911150: kvm_mmu_get_page: existing sp gfn 7fe65 1/2 q3 --- !pge !nxe root 0 sync qemu-system-i38-32767 [002] 55142.911151: kvm_mmu_get_page: existing sp gfn 7fe66 1/2 q3 --- !pge !nxe root 0 sync qemu-system-i38-32767 [002] 55142.911151: kvm_mmu_get_page: existing sp gfn 7fe67 1/2 q3 --- !pge !nxe root 0 sync qemu-system-i38-32767 [002] 55142.911151: kvm_mmu_get_page: existing sp gfn 7fe68 1/2 q3 --- !pge !nxe root 0 sync qemu-system-i38-32767 [002] 55142.911152: kvm_entry: vcpu 0 qemu-system-i38-32767 [002] 55142.911152: kvm_exit: reason EXCEPTION_NMI rip 0x7ffdb6b2 info 7fe88760 80000b0e qemu-system-i38-32767 [002] 55142.911153: kvm_page_fault: address 7fe88760 error_code b And then the last triplet is repeated infinitely. 0x7ffdb6b2 is the address of the same first instruction executed after the RSM. The address 0x7fe88760 seems to fall into an EfiBootServicesData allocation, made in PEI (via a suitable HOB): Memory Allocation 0x00000004 0x7FE69000 - 0x7FE88FFF Thanks Laszlo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
