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

[Denis Mukhin <dmkhn@xxxxxxxxx>]

On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné 
<roger.pau@xxxxxxxxxx> wrote:

> 
> 
> On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> 
> > On 08.01.2025 09:04, Roger Pau Monné wrote:
> > 
> > > 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.
> > 
> > Hmm, that's an aspect I have to admit I didn't think of.
> > 
> > > 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).
> > 
> > That's largely what aiui was proposed. My extra requirement there would
> > then be that we make sure a log message is always emitted when console
> > focus shifts, so it's possible to identify the owner for any part of
> > the log.
> 
> 
> Indeed, printing console input shifting should be a requirement
> regardless of how we decide to print the prefix.

Console input focus switch is indicated after pressing Crtl+aaa, e.g.:
[[
...
(XEN) [15359.353038] *** Serial input to Xen (type 'CTRL-aaa' to switch input)
(XEN) [15361.176754] *** Serial input to DOM0 (type 'CTRL-aaa' to switch input)
(XEN) [15711.297202] *** Serial input to DOM1 (type 'CTRL-aaa' to switch input)
...
]]

> 
> Thanks, Roger.