[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#611832: linux-image-2.6.32-5-amd64: general protection fault at reboot under qemu: native_stop_other_cpus+0x86/0x90



Ben Hutchings <ben@decadent.org.uk> writes:
> It's a kernel feature to be more efficient when running in a recognised
> virtual machine implementation (PV = paravirtualisation).

thanks. I think it is the following code from vmi_32.c:

/*
 * Apply patch if appropriate, return length of new instruction
 * sequence.  The callee does nop padding for us.
 */
static unsigned vmi_patch(u8 type, u16 clobbers, void *insns,
                          unsigned long ip, unsigned len)
{
        switch (type) {
                case PARAVIRT_PATCH(pv_irq_ops.irq_disable):
                        return patch_internal(VMI_CALL_DisableInterrupts, len,
                                              insns, ip);
                case PARAVIRT_PATCH(pv_irq_ops.irq_enable):
                        return patch_internal(VMI_CALL_EnableInterrupts, len,
                                              insns, ip);
                case PARAVIRT_PATCH(pv_irq_ops.restore_fl):
                        return patch_internal(VMI_CALL_SetInterruptMask, len,
                                              insns, ip);
                case PARAVIRT_PATCH(pv_irq_ops.save_fl):
                        return patch_internal(VMI_CALL_GetInterruptMask, len,
                                              insns, ip);
                case PARAVIRT_PATCH(pv_cpu_ops.iret):
                        return patch_internal(VMI_CALL_IRET, len, insns, ip);
                case PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit):
                        return patch_internal(VMI_CALL_SYSEXIT, len, insns, ip);
                default:
                        break;
        }
        return len;
}

I don't understand how the first xchg instruction in

0x0000000000600889 <f+41>:       57     push   %rdi
0x000000000060088a <f+42>:       9d     popfq
0x000000000060088b <f+43>:       66 66 90       xchg   %ax,%ax
0x000000000060088e <f+46>:       66 90  xchg   %ax,%ax

can generate a general protection fault. I googled around and found

   "yes - it smells like it tries to deliver vector 0, after the panic
    code has deinitialized the lapic / ioapic"

which suggests a qemu bug from
http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-09/msg09652.html

Shall I reassign the bug or do you know how to investigate this more?




Reply to: