Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()

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

On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> On 08.01.2025 00:40, Stefano Stabellini wrote:
> > On Tue, 7 Jan 2025, Jan Beulich wrote:
> >> On 06.01.2025 19:48, Stefano Stabellini wrote:
> >>> On Mon, 6 Jan 2025, Jan Beulich wrote:
> >>>> On 04.01.2025 05:15, Denis Mukhin wrote:
> >>>>>
> >>>>> On Tuesday, December 10th, 2024 at 11:28 PM, Jan Beulich 
> >>>>> <jbeulich@xxxxxxxx> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> >>>>>>
> >>>>>>> From: Denis Mukhin dmukhin@xxxxxxxx
> >>>>>>>
> >>>>>>> console_owner_domid() is introduced to obtain the "console owner" 
> >>>>>>> domain ID.
> >>>>>>>
> >>>>>>> The call is used in NS8250 emulator to identify the case when 
> >>>>>>> physical xen
> >>>>>>> console focus is owned by the domain w/ NS8250 emulator, in which 
> >>>>>>> case,
> >>>>>>> messages from guest OS are formatted w/o '(XEN)' prefix.
> >>>>>>
> >>>>>>
> >>>>>> Such messages ought to be processed through guest_printk(), which 
> >>>>>> wants a
> >>>>>> domain pointer, not a domid_t anyway. Plus isn't that going to be
> >>>>>> current->domain anyway at the callsite, eliminating the need for such a
> >>>>>>
> >>>>>> helper altogether?
> >>>>>
> >>>>> If the current domain is owning the physical console and printing, say, 
> >>>>> Linux
> >>>>> login prompt, there's no need to add "(XEN)" for every printout; adding 
> >>>>> timestamps
> >>>>> can be disabled from Xen command line.
> >>>>
> >>>> Surely there shouldn't be (XEN), but without (d<N>) it'll be ambiguous 
> >>>> in a log
> >>>> which domain a message came from. As long as only Dom0 messages are left 
> >>>> un-
> >>>> prefixed, that's likely fine. Yet as soon as multiple domains can issue 
> >>>> such
> >>>> messages (and have console "focus") I think the prefix needs to be there.
> >>>
> >>> It looks like we are aligned on the desired behavior,
> >>
> >> Hmm, no, I don't think we are. I don't ...
> >>
> >>> but for clarity,
> >>> see https://marc.info/?l=xen-devel&m=173405161613716, also copy/pasted
> >>> here:
> >>>
> >>> I think we should provide a consistent behavior across architectures.
> >>> The current behavior with vpl011 and dom0less on ARM is the following:
> >>>
> >>> - no prefix for Dom0 output
> >>> - DOM$NUM for DomUs when not in focus, otherwise no prefix
> >>
> >> ... view this model as a desirable one. It leaves room for ambiguity.
> > 
> > Adding a few more people in CC for feedback.
> > 
> > My priority is to keep the architectures aligned. It might be OK to
> > change output format, but then let's do it uniformly on ARM as well.
> > 
> > Jan, please clarify what you think would be better than the above. Is it
> > the following? I don't think I understood your preference.
> > 
> > - DOM$NUM for Dom0 and DomUs when not in focus, otherwise no prefix
> 
> No, I mean like we have it with guest_printk() today. (XEN) for Xen's
> own messages, (d<N>) for ordinary domains' ones, and no prefix
> exclusively for the hardware/control domain. What is best to do when
> hardware and control domains are distinct I'm uncertain - I'd be
> inclined to suggest that the hardware domain then stay the one without
> any prefix.

One concern I have with this approach is whether the addition of the
(d<N>) prefixes will skew output of interactive applications.  So far
the prefix is added to output from all domains different than dom0
because the console is not interactive for them, and hence no input
can be consumed.

If that changes however, and domains different than dom0 can get input
from the Xen console then I wonder how much the added prefix will skew
output.  Another possible option would be to not print the prefix for
the domain that has the console input assigned (current target), and
print it for all other domains (even for dom0 when not in focus).

Thanks, Roger.