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