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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Luca Tettamanti wrote:
> 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 just committed a patch which prevented .init from being set to 1 on 
cpu_index == 0.

> I
> still don't understand which check is failing though...
>
>   

These are tough...

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

It may have been timing.  kvm continued to run for a bit, reaching a 
non-emulated instruction, and then the reset hit it in the face.  The 
reset is much quicker now.

We should probably both fix the kernel to handle reset-during-emulation 
correctly (one ugly way is to zero the instruction length if we're 
setting rip), and fix userspace to delay reset like it used to for 
compatibility with older kernels.

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