On 200629 2000, Alex Bennée wrote: > > Alexander Bulekov <1878...@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.
Ah that makes sense. It probably isn't a real issue, but I'll send patches with the changes you suggested below. Thank you > 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 >