On 5/25/25 21:16, Julian Ganz wrote:
Hi Richard,
May 25, 2025 at 2:14 PM, Richard Henderson wrote:
Having read the whole series now, I think it would be better to change the
TCGCPUOps.do_interrupt interface.
Instead of having each target call qemu_plugin_*, instead have each
do_interrupt return the discontinuity type, or 0 if the interrupt is blocked so
no state change.
Change to cpu_handle_exception would be of the form:
if (qemu_plugin_discon_enabled(cpu)) {
vaddr from = tcg_ops->get_pc(cpu);
unsigned ev = tcg_ops->do_interrupt(cpu);
if (ev) {
qemu_plugin_vcpu_discon_cb(cpu, ev, from);
}
} else {
tcg_ops->do_interrupt(cpu);
}
Personally, I'd be in favour of that. However, I do see some obstacles
to that.
Quite a few targets to call their do_interrupt function internally,
usually from their exec_interrupt. We would then handle that function's
return value at the call site?
Yes, I think we'd alter the return value of exec_interrupt to match
do_interrupt.
There's a comment about exec_interrupt may longjmp away, but that *appears* to be
historical. I couldn't identify an existing target that does that.
Also, some targets such as tricore only have a dummy/stub do_interrupt
and handle exceptions differently inside non-returning functions. For
those, we would call the hooks directly from there as we do now?
It may be only tricore. And you're right, it would be a non-trivial reorg to make tricore
fall in line with other implementations. So retaining the separate
qemu_plugin_vcpu_exception_cb will be required in the short term.
And then we have some targets that deviate in some other way. For
example, s390x_cpu_do_interrupt effectively contains a loop, and we
potentially need to call one of the hooks for each iteration.
That is distinctly odd. I don't understand what's going on there.
David, can you elucidate re ce204cba74b? Is this intending to stack all outstanding
interrupts all at once, leaving the highest priority, then return-from-interrupt processes
the lower priorities? It's definitely unusual, but most things about s390x are... :-)
r~
