On Thu, Dec 12, 2024 at 01:52:49PM +0100, Jan Beulich wrote: > On 12.12.2024 13:15, Roger Pau Monné wrote: > > On Thu, Dec 12, 2024 at 12:57:25PM +0100, Jan Beulich wrote: > >> On 12.12.2024 10:14, Roger Pau Monné wrote: > >>> On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote: > >>>> From: Denis Mukhin <dmuk...@ford.com> > >>>> > >>>> Introduce new printk() variant for convenient printouts which skip > >>>> '(XEN)' > >>>> prefix on xen console. This is needed for the case when physical console > >>>> is > >>>> owned by a domain w/ in-hypervisor UART emulation enabled. > >>> > >>> IIRC the ns8250 can only send or receive one byte (character) at a > >>> time, so you should likely put that on the console as soon as it's > >>> received? > >>> > >>> For the hardware domain we explicitly don't buffer writes to the > >>> console (see guest_console_write() hardware domain special handling). > >>> > >>> I wonder however how you deal with domains that don't have the console > >>> focus (ie: != console_rx), as for those I think you still want to use > >>> the (d<domid>) prefix? > >> > >> Imo no matter what domain has the focus, the (d<domid>) prefix should > >> always be logged. Just to avoid possible confusion. > > > > WE don't do that currently for the hardware domain, because we avoid > > doing any kind of line processing, as characters from the hardware > > domain are send straight to the console without waiting for the > > newline terminator (like we do for other domains). > > Right, and that's kind of special, and aiui intentionally so. These are > the only un-prefixed lines logged. > > > Are you suggesting that in case of the console input being shared > > between multiple domains they should all be treated as plain domUs and > > thus lines should be buffered? > > No, I'm actually not suggesting anything here beyond perhaps reducing > the scope of this series to just what the equivalent of vpl011 would be > for the 8250 / 16550 case.
Indeed, reducing the scope would make it easier to get the actual feature reviewed. There's a huge amount of pre-patching that will possibly take some time to get agreement on (if suitable). Thanks, Roger.
