[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug 1878645] Re: null-ptr dereference in tcg_handle_interrupt
From: |
Alex Bennée |
Subject: |
Re: [Bug 1878645] Re: null-ptr dereference in tcg_handle_interrupt |
Date: |
Mon, 29 Jun 2020 20:00:44 +0100 |
User-agent: |
mu4e 1.5.3; emacs 28.0.50 |
Alexander Bulekov <1878645@bugs.launchpad.net> writes:
> I don't think this is a qtest-specific error:
> cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
> o/4 0xcf8 0x8400f841
> o/4 0xcfc 0xaa215d6d
> o/4 0x6d30 0x2ef8ffbe
> o/1 0xb2 0x20
> EOF
>
> ...
> Segmentation fault
Both this and the qtest have the same problem of depending on
current_cpu which is a TLS variable which will never be correct from the
qtest or monitor context. There are only a few other cases.
sun4m:cpu_halt_signal does:
if (level && current_cpu) {
cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
}
pxa2xx:pxa2xx_pwrmode_write does a bare:
/* Suspend */
cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
but given the context has a CPUARMState *env it could arguably use that
to derive current_cpu but as it's only triggered by a system register
write you can't actually trigger from a monitor/qtest command.
I would suggest either:
} else if (current_cpu) {
cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
}
or possibly:
} else {
cpu_interrupt(current_cpu ? current_cpu : first_cpu,
CPU_INTERRUPT_SMI);
}
if you really care about triggering a real IRQ from outside the CPU context.
--
Alex Bennée