Re: [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.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/