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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
