From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Problem with KVM guest switching to x86 long mode Date: Thu, 08 Apr 2010 22:30:59 +0300 Message-ID: <4BBE2EF3.6010304@redhat.com> References: <4BBE2213.6020802@redhat.com> <4BBE277B.1090908@cs.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM General To: Pekka Enberg Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53430 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933460Ab0DHTbM (ORCPT ); Thu, 8 Apr 2010 15:31:12 -0400 In-Reply-To: <4BBE277B.1090908@cs.helsinki.fi> Sender: kvm-owner@vger.kernel.org List-ID: On 04/08/2010 09:59 PM, Pekka Enberg wrote: > >>> 2b:* cb lret<-- trapping instruction >> >> Post the two u32s at ss:rsp -> ss:rsp+8. That will tell us where the >> guest is trying to return. Actually, from the dump: >> >> 1a: 6a 10 pushq $0x10 >> 1c: 8d 85 00 02 00 00 lea 0x200(%rbp),%eax >> 22: 50 push %rax >> >> it looks like you're returning to segment 0x10, this should be the >> word at ss:rsp+4. So if you dump the 2 u32s at >> gdtr.base+0x10..gdtr.base+0x18 we'll see if there's anything wrong >> with the segment descriptor. > > Here you go: I was asking for the wrong things. > > penberg@tiger:~/vm$ ./kvm bzImage > KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN") > Registers: > rip: 00000000001000ed rsp: 00000000005d54b8 flags: 0000000000010046 > rax: 0000000080000001 rbx: 0000000001f2c000 rcx: 00000000c0000080 > rdx: 0000000000000000 rsi: 0000000000013670 rdi: 0000000002408000 > rbp: 0000000000100000 r8: 0000000000000000 r9: 0000000000000000 > r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000 > r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000 > cr0: 0000000080000011 cr2: 00000000001000ed cr3: 0000000002402000 cr2 points at rip. So it isn't lret not executing correctly, it's the cpu not able to fetch lret at all. The code again: > 23: b8 01 00 00 80 mov $0x80000001,%eax > 28: 0f 22 c0 mov %rax,%cr0 > 2b:* cb lret<-- trapping instruction > The instruction at 0x28 is enabling paging, next insn fetch faults, so the paging structures must be incorrect. Questions: - what is the u64 at cr3? (call it pte4) - what is the u64 at (pte4 & ~0xfff)? (call it pte3) - what is the u64 at (pte3 & ~0xfff)? ("pte2") - what is the u64 at ((pte2 & ~0xfff) + 2048)? ("pte1") Note if bit 7 of pte2 is set, then pte1 is unneeded. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.