On 08.02.2024 23:00, Julien Grall wrote: > On 05/02/2024 13:27, Jan Beulich wrote: >> In preparation of dropping the register parameters from >> serial_[rt]x_interrupt() and in turn from IRQ handler functions, >> register state needs making available another way for the few key >> handlers which need it. Fake IRQ-like state. >> >> Signed-off-by: Jan Beulich <[email protected]> >> --- >> The use of guest_cpu_user_regs() in dbc_uart_poll() is inconsistent with >> other console poll functions we have, and it's unclear whether that's >> actually generally correct. > > Is it? Looking at ns16550_poll() we would pass guest_user_regs() if > run_in_exception() doesn't exist. But looking at the caller, no-on seems > to care about the 'regs'. So is this just a latent bug?
What do you mean by "doesn't exist"? ns16550_poll() assumes it exists. And I can spot any use of guest_user_regs() on the respective generic or Arm-specific bug.c paths. > BTW, do you have an idea why the poll function is not run in an > exception handler? "The poll function" being which one? If you mean the one in xhci-dbc.c then that's why I had Cc-ed Marek. Moving him to To: - maybe that manages to finally catch his attention. >> Andrew suggested to move set_irq_regs() to BUGFRAME_run_fn handling; >> it's not clear to me whether that would be (a) correct from an abstract >> pov (that's exception, not interrupt context after all) > > I agree with that. > >> and (b) really beneficial. > > I guess this could help to reduce the amount of churn. I can't really > make my mind whether this is worth it or not. So I would keep it as you did. Good, thanks. Jan
