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

[Luca Tettamanti <kronos.it-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Il Sun, Sep 09, 2007 at 03:51:20PM +0300, Avi Kivity ha scritto: 
> 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.

The reset has already been done by qmeu_system_reset(), so it's
superfluous. Furthermore, the extra reset causes the vmentry failure. I
still don't understand which check is failing though...

>>   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.

Ok, the culprit really is skip_emulated_instruction: skipping the
increment when EIP is 0xfff0 allows rebooting (yes, it's disgusting...)

So I think that there are two different issues:

1) Extra reset in update_regs_for_init causes vm entry failure due to
   invalid guest state

2) The emulator is doing something wrong since it used to handle the
   reset just fine

Luca
-- 
Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un
uomo sposa una donna sperando che non cambi, e lei cambiera`.

-------------------------------------------------------------------------
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/