Re: [PATCH v2 16/35] xen/console: introduce printk_common()

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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 <dmukhin@xxxxxxxx>
> >>>>
> >>>> 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.