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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan