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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan