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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan