On 21.01.2025 23:56, Jason Andryuk wrote: > On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote: >> --- a/xen/drivers/char/console.c >> +++ b/xen/drivers/char/console.c > >> @@ -579,6 +571,9 @@ static void __serial_rx(char c) >> if ( pv_shim && pv_console ) >> consoled_guest_tx(c); >> #endif >> + >> + if ( rc ) >> + printk(KERN_ERR "d%pd: failed to process console input: %d\n", d, >> rc); >> } >> >> static void cf_check serial_rx(char c) >> > > This will print the ENOSPC that was formerly silent. Since this is > input from the console, that seems more informative to the user and okay > to me.
I don't view this as okay. For one it needs to be a guest log level, such that rate limiting can suitably suppress too many of these messages in a short time (which in particular might happen if the ENOSPC reason isn't dealt with by the receiving domain). And then I wonder whether this wouldn't better be even more strongly limited, perhaps to just once per domain. I'm also unconvinced of KERN_ERR - from Xen's perspective nothing error- like has happened, once again most notably for the ENOSPC case. I'd view this as a warning at best. Finally: Why d%pd? It ought to be just %pd. Jan
