From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083 Date: Sun, 09 Sep 2007 15:51:20 +0300 Message-ID: <46E3EC48.60004@qumranet.com> References: <20070811212520.GA26794@dreamland.darkstar.lan> <46C01FDA.9000302@qumranet.com> <68676e00708171314r4be1840bo95f5af50df6f7dfd@mail.gmail.com> <46C7F2E6.4030808@qumranet.com> <20070819195458.GA31865@dreamland.darkstar.lan> <46C949C1.90807@qumranet.com> <20070903210949.GA19919@dreamland.darkstar.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org, Uri Lublin To: Luca Tettamanti Return-path: In-Reply-To: <20070903210949.GA19919-sTXFmx6KbOnUXq0IF5SVAZ4oGUkBHcCu@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Luca Tettamanti wrote: >> Actually 0xfff2 is in the middle of an instruction. >> >> I'm guessing an 'out' instruction triggered the reboot, and >> skip_emulated_instruction() added 2 to rip. >> > > I think you're right; the reset is triggered by an outb to 0x64. > > Now, with this patch: > > diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c > index 491c32c..722d838 100644 > --- a/qemu/qemu-kvm.c > +++ b/qemu/qemu-kvm.c > @@ -706,8 +706,12 @@ static void update_regs_for_sipi(CPUState *env) > > static void update_regs_for_init(CPUState *env) > { > - cpu_reset(env); > - load_regs(env); > + if (env->cpu_index) { > + cpu_reset(env); > + load_regs(env); > + } else { > + vcpu_info[env->cpu_index].init = 0; > + } > } > Can you explain this patch? Why is the boot cpu treated differently? I think the only difference should be the halted flag. > > static void setup_kernel_sigmask(CPUState *env) > > I can reboot using the BIOS (reboot=b) without the outb. I fail to see > why an extra reset causes the vm entry failure though. > > Default reboot path (i.e. the outb) still fails: > > exception 13 (0) > rax 0000000000000000 rbx 0000000000000000 rcx 000000000000ffff rdx 0000000000000700 > rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp 0000000000000000 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 > rip 000000000000ffff rflags 00033046 > cs f000 (000f0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0080 (10850000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt 0/ffff > idt 0/ffff > cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > the #GP makes more sense than the vm entry failure if the the emulator > is jumping to fff2. > Right. Maybe the processor dropped out of vm86 mode and we're getting #gp on ds. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/