Ben Hutchings <b...@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?
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84oc6d5jga....@sauna.l.org
