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