All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
	roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 2/2] xen/console: unify printout behavior for UART emulators
Date: Tue, 10 Jun 2025 08:43:55 +0200	[thread overview]
Message-ID: <ba196894-7a02-4daf-b736-dd5f0889188d@suse.com> (raw)
In-Reply-To: <aENFsfo8J5HGg4tN@kraken>

On 06.06.2025 21:47, dmkhn@proton.me wrote:
> On Fri, Jun 06, 2025 at 09:12:06AM +0200, Jan Beulich wrote:
>> On 06.06.2025 09:06, dmkhn@proton.me wrote:
>>> On Thu, Jun 05, 2025 at 08:18:34AM +0200, Jan Beulich wrote:
>>>> On 05.06.2025 02:46, dmkhn@proton.me wrote:
>>>>> From: Denis Mukhin <dmukhin@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)".
>>>>>
>>>>> Use guest_printk() without rate-limiting in all current in-hypervisor UART
>>>>> emulators. That aligns the behavior with debug I/O port 0xe9 handler on x86 and
>>>>> slightly improves the logging since guest_printk() already prints the domain
>>>>> ID. guest_printk() was modified to account for console focus ownership.
>>>>>
>>>>> Modify guest_console_write() for hardware domain case by adding domain ID to
>>>>> the message when hwdom does not have console focus.
>>>>>
>>>>> [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463523@ubuntu-linux-20-04-desktop/
>>>>> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>>>>> ---
>>>>> Changes since v1:
>>>>> - dropped change for debug port and for HYPERVISOR_console_io hypercall
>>>>
>>>> Yet then what about ...
>>>>
>>>>> --- a/xen/arch/arm/vuart.c
>>>>> +++ b/xen/arch/arm/vuart.c
>>>>> @@ -89,7 +89,7 @@ static void vuart_print_char(struct vcpu *v, char c)
>>>>>          if ( c != '\n' )
>>>>>              uart->buf[uart->idx++] = '\n';
>>>>>          uart->buf[uart->idx] = '\0';
>>>>> -        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
>>>>> +        guest_printk(d, "%s", uart->buf);
>>>>>          uart->idx = 0;
>>>>>      }
>>>>>      spin_unlock(&uart->lock);
>>>>
>>>> ... this dropping of XENLOG_G_DEBUG? In fact I'd have expected such to
>>>> be _added_ where presently missing.
>>>
>>> vUART is a debugging facility. This flavor of UART is specifically for guest OS
>>> early boot debugging.
>>> I think it is not desirable to potentially lose guest messages while doing such
>>> early guest OS boot debugging.
>>
>> That is the host admin's decision, not a policy we should enforce.
> 
> re: policy: agreed, I will drop that hunk.
> 
> I think for the policy control, there can be a compile time setting (separate
> patch) which enables/disables the debug output rate-limiting - and that setting
> applies to:
>   - vUARTs (currently vpl011 and "vuart", later ns16550 (x86) and upcoming
>     emulator for RISC-V)
>   - debug port on x86
>   - HYPERVISOR_console_io
> 
> What do you think?

I'm not convinced, but much would depend on the justification for such a change.

Jan


      reply	other threads:[~2025-06-10  6:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05  0:46 [PATCH v2 0/2] xen/console: updates to diagnostic messages prefixes dmkhn
2025-06-05  0:46 ` [PATCH v2 1/2] xen/console: introduce CONSOLE_PREFIX dmkhn
2025-06-05  0:46 ` [PATCH v2 2/2] xen/console: unify printout behavior for UART emulators dmkhn
2025-06-05  6:18   ` Jan Beulich
2025-06-06  7:06     ` dmkhn
2025-06-06  7:12       ` Jan Beulich
2025-06-06 19:47         ` dmkhn
2025-06-10  6:43           ` Jan Beulich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ba196894-7a02-4daf-b736-dd5f0889188d@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=dmkhn@proton.me \
    --cc=dmukhin@ford.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.