On 11.06.2025 02:07, dm...@proton.me wrote:
> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>> On 06.06.2025 22:11, dm...@proton.me wrote:
>>> From: Denis Mukhin <dmuk...@ford.com>
>>>
>>> If virtual UART from domain X prints on the physical console, the behavior
>>> is
>>> updated to (see [1]):
>>> - console focus in domain X: do not prefix messages;
>>> - no console focus in domain X: prefix all messages with "(dX)".
>>
>> While, as indicated (much) earlier, I can see why omitting the prefix
>> may make sense for the domain having input focus, ...
>>
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -740,7 +740,17 @@ static long
>>> guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>>> if ( is_hardware_domain(cd) )
>>> {
>>> /* Use direct console output as it could be interactive */
>>> + char prefix[16] = "";
>>> + struct domain *consd;
>>> +
>>> + consd = console_get_domain();
>>> + if ( consd != cd )
>>> + snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
>>> + console_put_domain(consd);
>>> +
>>> nrspin_lock_irq(&console_lock);
>>> + if ( prefix[0] != '\0' )
>>> + console_send(prefix, strlen(prefix), flags);
>>> console_send(kbuf, kcount, flags);
>>> nrspin_unlock_irq(&console_lock);
>>> }
>>
>> ... this, aiui, is a behavioral change for the non-dom0less case, where
>> Dom0 output will suddenly also gain the prefix. Which I don't think is
>> wanted: Switching focus between Xen and Dom0 should remain unaffected
>> in this regard.
>
> This change ensures that dom0 traces aren't mixed with domU traces when domU
> has input focus, or with Xen traces when the administrator is in the
> diagnostic
> console.
That's what the description also tries to describe, yet I still regard it as
a behavioral regression in (at least) the described scenario. The hardware
domain presently not having (d0) prefixed to its output is deliberate imo,
not accidental.
Jan
