On 11.01.2024 17:08, Andrew Cooper wrote: > On 11/01/2024 3:49 pm, Jan Beulich wrote: >> On 11.01.2024 16:24, Andrew Cooper wrote: >>> On 11/01/2024 12:11 pm, Jan Beulich wrote: >>> It does occur to me that we're trying to accommodate for two behaviours >>> here. >>> >>> For a real keypress, we want to dump from the the point the interrupt >>> hit because that's the interesting bit of stack to see. For a SYSCTL, >>> there's nothing, and we're using BUGFRAME_run_fn to generate one. >> There's three forms of handle_keypress() invocations really, and hence >> why (after having dropped the regs parameter already) I re-instated it. > > Ok. As you've done this analysis work, can you list these 3 forms? > > I've clearly missed one in my analysis.
The console handler invocation is (now) using get_irq_regs(). The sysctl handling, as said, passes guest_cpu_user_regs(). And then there are two cases where NULL is passed, one from keypress_action() (a tasklet handler) and the other from keyhandler_crash_action(). I'm not convinced the latter is fully correct. The tasklet handler is used only for non-IRQ keys, and hence only in cases where regs wouldn't have been passed to the handler anyway. IOW - leaving the keyhandler_crash_action() uncertainty aside, I think it ought to be possible to do as you did suggest. Jan
