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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.01.2025 23:15, Denis Mukhin wrote:
> 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)
> ...
> ]]

And just to double check: These messages aren't affected by "loglvl=" settings,
i.e. they're _always_ there (as asked for earlier; see context above)?

Jan