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() 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 v2:
- dropped rate-limiting change for vuart
---
xen/arch/arm/vpl011.c | 6 +++---
xen/arch/arm/vuart.c | 2 +-
xen/drivers/char/console.c | 23 +++++++++++++++++++++--
3 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 480fc664fc..2b6f2a09bc 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
{
if ( intf->out_prod == 1 )
{
- printk("%c", data);
+ guest_printk(d, "%c", data);
intf->out_prod = 0;
}
else
@@ -95,7 +95,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
if ( data != '\n' )
intf->out[intf->out_prod++] = '\n';
intf->out[intf->out_prod++] = '\0';
- printk("%s", intf->out);
+ guest_printk(d, "%s", intf->out);
intf->out_prod = 0;
}
}
@@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
if ( data != '\n' )
intf->out[intf->out_prod++] = '\n';
intf->out[intf->out_prod++] = '\0';
- printk("DOM%u: %s", d->domain_id, intf->out);
+ guest_printk(d, "%s", intf->out);
intf->out_prod = 0;
}
}
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index bd2f425214..6641f9d775 100644
--- 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, XENLOG_G_DEBUG "%s", uart->buf);
uart->idx = 0;
}
spin_unlock(&uart->lock);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 6e77b4af82..3855962af7 100644
--- 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);
}
@@ -1032,12 +1042,21 @@ void printk(const char *fmt, ...)
va_end(args);
}
+/*
+ * Print message from the guest on the diagnostic console.
+ * Prefixes all messages w/ "(dX)" if domain X does not own physical console
+ * focus.
+ */
void guest_printk(const struct domain *d, const char *fmt, ...)
{
va_list args;
- char prefix[16];
+ char prefix[16] = "";
+ struct domain *consd;
- snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+ consd = console_get_domain();
+ if ( consd != d )
+ snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+ console_put_domain(consd);
va_start(args, fmt);
vprintk_common(fmt, args, prefix);
--
2.34.1On Fri, Jun 06, 2025 at 08:11:26PM +0000, 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() 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 v2:
> - dropped rate-limiting change for vuart
> ---
> xen/arch/arm/vpl011.c | 6 +++---
> xen/arch/arm/vuart.c | 2 +-
> xen/drivers/char/console.c | 23 +++++++++++++++++++++--
> 3 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 480fc664fc..2b6f2a09bc 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> {
> if ( intf->out_prod == 1 )
> {
> - printk("%c", data);
> + guest_printk(d, "%c", data);
> intf->out_prod = 0;
> }
> else
> @@ -95,7 +95,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> if ( data != '\n' )
> intf->out[intf->out_prod++] = '\n';
> intf->out[intf->out_prod++] = '\0';
> - printk("%s", intf->out);
> + guest_printk(d, "%s", intf->out);
> intf->out_prod = 0;
> }
> }
> @@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> if ( data != '\n' )
> intf->out[intf->out_prod++] = '\n';
> intf->out[intf->out_prod++] = '\0';
> - printk("DOM%u: %s", d->domain_id, intf->out);
> + guest_printk(d, "%s", intf->out);
> intf->out_prod = 0;
> }
> }
> diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
> index bd2f425214..6641f9d775 100644
> --- 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, XENLOG_G_DEBUG "%s", uart->buf);
> uart->idx = 0;
> }
> spin_unlock(&uart->lock);
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 6e77b4af82..3855962af7 100644
> --- 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);
> }
> @@ -1032,12 +1042,21 @@ void printk(const char *fmt, ...)
> va_end(args);
> }
>
> +/*
> + * Print message from the guest on the diagnostic console.
> + * Prefixes all messages w/ "(dX)" if domain X does not own physical console
> + * focus.
> + */
> void guest_printk(const struct domain *d, const char *fmt, ...)
> {
> va_list args;
> - char prefix[16];
> + char prefix[16] = "";
> + struct domain *consd;
>
> - snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> + consd = console_get_domain();
> + if ( consd != d )
> + snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> + console_put_domain(consd);
It might be helpful to abstract this into a separate helper, as it's
used by both functions:
static void fill_console_prefix(char *prefix, unsigned int len,
const struct domain *d)
{
struct domain *consd = console_get_domain();
if ( consd ? consd != d : !is_hardware_domain(d)) )
snprintf(prefix, len, "(d%d) ", d->domain_id);
console_put_domain(consd);
}
Note the above code should also handle the current discussion of not
printing the (d0) prefix for the hardware domain when the console
target is Xen. I think this keeps the previous behavior when console
input is switched to Xen, while still providing unified (dX) prefixes
otherwise.
Thanks, Roger.
On Wed, Jun 25, 2025 at 12:50:57PM +0200, Roger Pau Monné wrote:
> On Fri, Jun 06, 2025 at 08:11:26PM +0000, 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() 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 v2:
> > - dropped rate-limiting change for vuart
> > ---
> > xen/arch/arm/vpl011.c | 6 +++---
> > xen/arch/arm/vuart.c | 2 +-
> > xen/drivers/char/console.c | 23 +++++++++++++++++++++--
> > 3 files changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 480fc664fc..2b6f2a09bc 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> > {
> > if ( intf->out_prod == 1 )
> > {
> > - printk("%c", data);
> > + guest_printk(d, "%c", data);
> > intf->out_prod = 0;
> > }
> > else
> > @@ -95,7 +95,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> > if ( data != '\n' )
> > intf->out[intf->out_prod++] = '\n';
> > intf->out[intf->out_prod++] = '\0';
> > - printk("%s", intf->out);
> > + guest_printk(d, "%s", intf->out);
> > intf->out_prod = 0;
> > }
> > }
> > @@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> > if ( data != '\n' )
> > intf->out[intf->out_prod++] = '\n';
> > intf->out[intf->out_prod++] = '\0';
> > - printk("DOM%u: %s", d->domain_id, intf->out);
> > + guest_printk(d, "%s", intf->out);
> > intf->out_prod = 0;
> > }
> > }
> > diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
> > index bd2f425214..6641f9d775 100644
> > --- 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, XENLOG_G_DEBUG "%s", uart->buf);
> > uart->idx = 0;
> > }
> > spin_unlock(&uart->lock);
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 6e77b4af82..3855962af7 100644
> > --- 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);
> > }
> > @@ -1032,12 +1042,21 @@ void printk(const char *fmt, ...)
> > va_end(args);
> > }
> >
> > +/*
> > + * Print message from the guest on the diagnostic console.
> > + * Prefixes all messages w/ "(dX)" if domain X does not own physical console
> > + * focus.
> > + */
> > void guest_printk(const struct domain *d, const char *fmt, ...)
> > {
> > va_list args;
> > - char prefix[16];
> > + char prefix[16] = "";
> > + struct domain *consd;
> >
> > - snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> > + consd = console_get_domain();
> > + if ( consd != d )
> > + snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
> > + console_put_domain(consd);
>
> It might be helpful to abstract this into a separate helper, as it's
> used by both functions:
>
> static void fill_console_prefix(char *prefix, unsigned int len,
> const struct domain *d)
> {
> struct domain *consd = console_get_domain();
>
> if ( consd ? consd != d : !is_hardware_domain(d)) )
> snprintf(prefix, len, "(d%d) ", d->domain_id);
> console_put_domain(consd);
> }
>
> Note the above code should also handle the current discussion of not
> printing the (d0) prefix for the hardware domain when the console
> target is Xen. I think this keeps the previous behavior when console
> input is switched to Xen, while still providing unified (dX) prefixes
> otherwise.
Thanks, will do.
>
> Thanks, Roger.
>
On 06.06.2025 22:11, 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)".
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.
Jan
On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> On 06.06.2025 22:11, 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)".
>
> 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.
Also, this can be used in the non-interactive tests (e.g. XTF).
>
> Jan
>
On 11.06.2025 02:07, dmkhn@proton.me wrote:
> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>> On 06.06.2025 22:11, 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)".
>>
>> 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
On Wed, 11 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> > On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >> On 06.06.2025 22:11, 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)".
> >>
> >> 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.
If we only consider the classic dom0 and dom0less usage models, then
what you wrote makes perfect sense. In the classic dom0 case, it is best
for dom0 to have no prefix, which is the current behavior.
However, things become more complex with dom0less. As we have discussed
previously, it has already become desirable on both ARM and x86 to align
on the same behavior. During our last discussion, the preference was to
add a '(d0)' prefix to clearly differentiate output from dom0 and other
domains.
Up to now, we could easily detect the two different cases depending on
the boot configuration. The problem arises with Denis' patches, which
add the ability for dynamically created guests via `xl` to access an
emulated NS16550 UART that prints to the console. Because these guests
are created dynamically, it is not clear how we are going to handle
this case.
If we follow the dom0less preference, then we would need a '(d0)' prefix
for dom0. If we follow the classic dom0 model, then dom0 would remain
without a prefix, and the new domUs would have a prefix. This would
cause an inconsistency. However, this is what we have today on ARM with
dom0less.
If Jan feels strongly that we should retain no prefix for the classic
dom0 case, which is understandable, then I believe the best course of
action would be to change our stance on dom0less on both ARM and x86 and
also use no prefix for dom0 in the dom0less case (which is the current
state on ARM).
On 11.06.2025 21:07, Stefano Stabellini wrote:
> On Wed, 11 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>> On 06.06.2025 22:11, 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)".
>>>>
>>>> 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.
>
> If we only consider the classic dom0 and dom0less usage models, then
> what you wrote makes perfect sense. In the classic dom0 case, it is best
> for dom0 to have no prefix, which is the current behavior.
>
> However, things become more complex with dom0less. As we have discussed
> previously, it has already become desirable on both ARM and x86 to align
> on the same behavior. During our last discussion, the preference was to
> add a '(d0)' prefix to clearly differentiate output from dom0 and other
> domains.
>
> Up to now, we could easily detect the two different cases depending on
> the boot configuration. The problem arises with Denis' patches, which
> add the ability for dynamically created guests via `xl` to access an
> emulated NS16550 UART that prints to the console. Because these guests
> are created dynamically, it is not clear how we are going to handle
> this case.
Why would this be not clear? We already prefix their output with "(d<N>)"
when going the traditional way. The same would then apply to output
coming through the emulated UART.
> If we follow the dom0less preference, then we would need a '(d0)' prefix
> for dom0. If we follow the classic dom0 model, then dom0 would remain
> without a prefix, and the new domUs would have a prefix. This would
> cause an inconsistency. However, this is what we have today on ARM with
> dom0less.
>
> If Jan feels strongly that we should retain no prefix for the classic
> dom0 case, which is understandable, then I believe the best course of
> action would be to change our stance on dom0less on both ARM and x86 and
> also use no prefix for dom0 in the dom0less case (which is the current
> state on ARM).
Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
I disagree. Present behavior of not prefixing the domain's output which
has input focus continues to make sense. That requires Dom0 to have a
prefix whenever it doesn't have input focus.
Jan
On Thu, 12 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 21:07, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>> On 06.06.2025 22:11, 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)".
> >>>>
> >>>> 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.
> >
> > If we only consider the classic dom0 and dom0less usage models, then
> > what you wrote makes perfect sense. In the classic dom0 case, it is best
> > for dom0 to have no prefix, which is the current behavior.
> >
> > However, things become more complex with dom0less. As we have discussed
> > previously, it has already become desirable on both ARM and x86 to align
> > on the same behavior. During our last discussion, the preference was to
> > add a '(d0)' prefix to clearly differentiate output from dom0 and other
> > domains.
> >
> > Up to now, we could easily detect the two different cases depending on
> > the boot configuration. The problem arises with Denis' patches, which
> > add the ability for dynamically created guests via `xl` to access an
> > emulated NS16550 UART that prints to the console. Because these guests
> > are created dynamically, it is not clear how we are going to handle
> > this case.
>
> Why would this be not clear? We already prefix their output with "(d<N>)"
> when going the traditional way. The same would then apply to output
> coming through the emulated UART.
>
> > If we follow the dom0less preference, then we would need a '(d0)' prefix
> > for dom0. If we follow the classic dom0 model, then dom0 would remain
> > without a prefix, and the new domUs would have a prefix. This would
> > cause an inconsistency. However, this is what we have today on ARM with
> > dom0less.
> >
> > If Jan feels strongly that we should retain no prefix for the classic
> > dom0 case, which is understandable, then I believe the best course of
> > action would be to change our stance on dom0less on both ARM and x86 and
> > also use no prefix for dom0 in the dom0less case (which is the current
> > state on ARM).
>
> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
> I disagree. Present behavior of not prefixing the domain's output which
> has input focus continues to make sense. That requires Dom0 to have a
> prefix whenever it doesn't have input focus.
If I understood correctly I like your proposal. Let me rephrase it to
make sure we are aligned. You are suggesting that:
- domains without input focus will print with a (d<N>) prefix
- the domain with input focus will print without a (d<N>) prefix
- this applies to both DomUs and Dom0
- this applies to both predefined domains and also dynamic domains
I am OK with that. I believe this is not the current behavior on ARM but
I can appreciate the simple consistency of it.
On 18.06.2025 02:39, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 21:07, Stefano Stabellini wrote:
>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>>>> On 06.06.2025 22:11, 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)".
>>>>>>
>>>>>> 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.
>>>
>>> If we only consider the classic dom0 and dom0less usage models, then
>>> what you wrote makes perfect sense. In the classic dom0 case, it is best
>>> for dom0 to have no prefix, which is the current behavior.
>>>
>>> However, things become more complex with dom0less. As we have discussed
>>> previously, it has already become desirable on both ARM and x86 to align
>>> on the same behavior. During our last discussion, the preference was to
>>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
>>> domains.
>>>
>>> Up to now, we could easily detect the two different cases depending on
>>> the boot configuration. The problem arises with Denis' patches, which
>>> add the ability for dynamically created guests via `xl` to access an
>>> emulated NS16550 UART that prints to the console. Because these guests
>>> are created dynamically, it is not clear how we are going to handle
>>> this case.
>>
>> Why would this be not clear? We already prefix their output with "(d<N>)"
>> when going the traditional way. The same would then apply to output
>> coming through the emulated UART.
>>
>>> If we follow the dom0less preference, then we would need a '(d0)' prefix
>>> for dom0. If we follow the classic dom0 model, then dom0 would remain
>>> without a prefix, and the new domUs would have a prefix. This would
>>> cause an inconsistency. However, this is what we have today on ARM with
>>> dom0less.
>>>
>>> If Jan feels strongly that we should retain no prefix for the classic
>>> dom0 case, which is understandable, then I believe the best course of
>>> action would be to change our stance on dom0less on both ARM and x86 and
>>> also use no prefix for dom0 in the dom0less case (which is the current
>>> state on ARM).
>>
>> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
>> I disagree. Present behavior of not prefixing the domain's output which
>> has input focus continues to make sense. That requires Dom0 to have a
>> prefix whenever it doesn't have input focus.
>
> If I understood correctly I like your proposal. Let me rephrase it to
> make sure we are aligned. You are suggesting that:
>
> - domains without input focus will print with a (d<N>) prefix
> - the domain with input focus will print without a (d<N>) prefix
> - this applies to both DomUs and Dom0
Except in the non-dom0less case, at least up and until there's at least
one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
regardless of the presence of e.g. "conswitch=".
Jan
> - this applies to both predefined domains and also dynamic domains
>
> I am OK with that. I believe this is not the current behavior on ARM but
> I can appreciate the simple consistency of it.
On Wed, 18 Jun 2025, Jan Beulich wrote:
> On 18.06.2025 02:39, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 21:07, Stefano Stabellini wrote:
> >>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> >>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>>>> On 06.06.2025 22:11, 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)".
> >>>>>>
> >>>>>> 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.
> >>>
> >>> If we only consider the classic dom0 and dom0less usage models, then
> >>> what you wrote makes perfect sense. In the classic dom0 case, it is best
> >>> for dom0 to have no prefix, which is the current behavior.
> >>>
> >>> However, things become more complex with dom0less. As we have discussed
> >>> previously, it has already become desirable on both ARM and x86 to align
> >>> on the same behavior. During our last discussion, the preference was to
> >>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
> >>> domains.
> >>>
> >>> Up to now, we could easily detect the two different cases depending on
> >>> the boot configuration. The problem arises with Denis' patches, which
> >>> add the ability for dynamically created guests via `xl` to access an
> >>> emulated NS16550 UART that prints to the console. Because these guests
> >>> are created dynamically, it is not clear how we are going to handle
> >>> this case.
> >>
> >> Why would this be not clear? We already prefix their output with "(d<N>)"
> >> when going the traditional way. The same would then apply to output
> >> coming through the emulated UART.
> >>
> >>> If we follow the dom0less preference, then we would need a '(d0)' prefix
> >>> for dom0. If we follow the classic dom0 model, then dom0 would remain
> >>> without a prefix, and the new domUs would have a prefix. This would
> >>> cause an inconsistency. However, this is what we have today on ARM with
> >>> dom0less.
> >>>
> >>> If Jan feels strongly that we should retain no prefix for the classic
> >>> dom0 case, which is understandable, then I believe the best course of
> >>> action would be to change our stance on dom0less on both ARM and x86 and
> >>> also use no prefix for dom0 in the dom0less case (which is the current
> >>> state on ARM).
> >>
> >> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
> >> I disagree. Present behavior of not prefixing the domain's output which
> >> has input focus continues to make sense. That requires Dom0 to have a
> >> prefix whenever it doesn't have input focus.
> >
> > If I understood correctly I like your proposal. Let me rephrase it to
> > make sure we are aligned. You are suggesting that:
> >
> > - domains without input focus will print with a (d<N>) prefix
> > - the domain with input focus will print without a (d<N>) prefix
> > - this applies to both DomUs and Dom0
>
> Except in the non-dom0less case, at least up and until there's at least
> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> regardless of the presence of e.g. "conswitch=".
In the non-dom0less case, since dom0 has focus, it would naturally be
without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I
wouldn't special-case conswitch= that way and would prefer keep things
simple and consistent without corner cases. I don't think conswitch= is
so widely used that it is worth the complexity to special-case it.
I am not going to insist though.
> > - this applies to both predefined domains and also dynamic domains
> >
> > I am OK with that. I believe this is not the current behavior on ARM but
> > I can appreciate the simple consistency of it.
>
Hi Stefano, On 19/06/2025 01:45, Stefano Stabellini wrote: > On Wed, 18 Jun 2025, Jan Beulich wrote: >> On 18.06.2025 02:39, Stefano Stabellini wrote: >>> On Thu, 12 Jun 2025, Jan Beulich wrote: >>>> On 11.06.2025 21:07, Stefano Stabellini wrote: >>>>> On Wed, 11 Jun 2025, Jan Beulich wrote: >>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote: >>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: >>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote: >>>>>>>>> From: Denis Mukhin <dmukhin@ford.com> >>> If I understood correctly I like your proposal. Let me rephrase it to >>> make sure we are aligned. You are suggesting that: >>> >>> - domains without input focus will print with a (d<N>) prefix >>> - the domain with input focus will print without a (d<N>) prefix >>> - this applies to both DomUs and Dom0 >> >> Except in the non-dom0less case, at least up and until there's at least >> one other domain. I.e. I'd like to keep Dom0 boot output as it is today, >> regardless of the presence of e.g. "conswitch=". > > In the non-dom0less case, since dom0 has focus, it would naturally be > without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I > wouldn't special-case conswitch= that way and would prefer keep things > simple and consistent without corner cases. I don't think conswitch= is > so widely used that it is worth the complexity to special-case it. I am a bit confused with the wording. Before I can provide another opinion, I want to understand a bit more the concern. From my understanding the command line option "conswitch" is to allow the admin to change with key is used to switch between Dom0 and Xen. By default this is 'a'. So are you referring to the fact a trailing "x" (to not switch to dom0 console) can be added? Cheers, -- Julien Grall
On Fri, 27 Jun 2025, Julien Grall wrote: > Hi Stefano, > > On 19/06/2025 01:45, Stefano Stabellini wrote: > > On Wed, 18 Jun 2025, Jan Beulich wrote: > > > On 18.06.2025 02:39, Stefano Stabellini wrote: > > > > On Thu, 12 Jun 2025, Jan Beulich wrote: > > > > > On 11.06.2025 21:07, Stefano Stabellini wrote: > > > > > > On Wed, 11 Jun 2025, Jan Beulich wrote: > > > > > > > On 11.06.2025 02:07, dmkhn@proton.me wrote: > > > > > > > > On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: > > > > > > > > > On 06.06.2025 22:11, dmkhn@proton.me wrote: > > > > > > > > > > From: Denis Mukhin <dmukhin@ford.com> > > > > If I understood correctly I like your proposal. Let me rephrase it to > > > > make sure we are aligned. You are suggesting that: > > > > > > > > - domains without input focus will print with a (d<N>) prefix > > > > - the domain with input focus will print without a (d<N>) prefix > > > > - this applies to both DomUs and Dom0 > > > > > > Except in the non-dom0less case, at least up and until there's at least > > > one other domain. I.e. I'd like to keep Dom0 boot output as it is today, > > > regardless of the presence of e.g. "conswitch=". > > > > In the non-dom0less case, since dom0 has focus, it would naturally be > > without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I > > wouldn't special-case conswitch= that way and would prefer keep things > > simple and consistent without corner cases. I don't think conswitch= is > > so widely used that it is worth the complexity to special-case it. > > I am a bit confused with the wording. Before I can provide another opinion, I > want to understand a bit more the concern. > > From my understanding the command line option "conswitch" is to allow the > admin to change with key is used to switch between Dom0 and Xen. By default > this is 'a'. So are you referring to the fact a trailing "x" (to not switch to > dom0 console) can be added? Yes, conswitch can also be used to ask Xen to keep the input focus to itself, instead of giving it away to Dom0. I think this is the specific feature Jan was referring to when he said he is using conswitch and the proposal would change the way the output looks like for him, which is true. Today, dom0 would still print without any prefix. Tomorrow with this proposal, dom0 would print with a "(d0)" prefix because it doesn't have input focus. The question is, with the new policy in place, whether this is worth the trouble of having a special case to remove the "(d0)" prefix in the conswitch=x case. I think it is not worth it, Jan thinks it is.
On 27.06.2025 23:58, Stefano Stabellini wrote: > On Fri, 27 Jun 2025, Julien Grall wrote: >> Hi Stefano, >> >> On 19/06/2025 01:45, Stefano Stabellini wrote: >>> On Wed, 18 Jun 2025, Jan Beulich wrote: >>>> On 18.06.2025 02:39, Stefano Stabellini wrote: >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote: >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote: >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote: >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote: >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote: >>>>>>>>>>> From: Denis Mukhin <dmukhin@ford.com> >>>>> If I understood correctly I like your proposal. Let me rephrase it to >>>>> make sure we are aligned. You are suggesting that: >>>>> >>>>> - domains without input focus will print with a (d<N>) prefix >>>>> - the domain with input focus will print without a (d<N>) prefix >>>>> - this applies to both DomUs and Dom0 >>>> >>>> Except in the non-dom0less case, at least up and until there's at least >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today, >>>> regardless of the presence of e.g. "conswitch=". >>> >>> In the non-dom0less case, since dom0 has focus, it would naturally be >>> without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I >>> wouldn't special-case conswitch= that way and would prefer keep things >>> simple and consistent without corner cases. I don't think conswitch= is >>> so widely used that it is worth the complexity to special-case it. >> >> I am a bit confused with the wording. Before I can provide another opinion, I >> want to understand a bit more the concern. >> >> From my understanding the command line option "conswitch" is to allow the >> admin to change with key is used to switch between Dom0 and Xen. By default >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to >> dom0 console) can be added? > > Yes, conswitch can also be used to ask Xen to keep the input focus to > itself, instead of giving it away to Dom0. I think this is the specific > feature Jan was referring to when he said he is using conswitch and the > proposal would change the way the output looks like for him, which is > true. > > Today, dom0 would still print without any prefix. > > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix > because it doesn't have input focus. > > The question is, with the new policy in place, whether this is worth the > trouble of having a special case to remove the "(d0)" prefix in the > conswitch=x case. I think it is not worth it, Jan thinks it is. Just to clarify: Along with this mode being entered by conswitch=, I also expect the behavior to remain unaltered when booting (non-dom0less) without that option, and later flipping focus between Xen and Dom0 by using triple Ctrl-a. I'm saying this just to make sure that an eventual change to the patch wouldn't be keyed to the use of the command line option. Jan
On Sun, Jun 29, 2025 at 03:47:41PM +0200, Jan Beulich wrote: > On 27.06.2025 23:58, Stefano Stabellini wrote: > > On Fri, 27 Jun 2025, Julien Grall wrote: > >> Hi Stefano, > >> > >> On 19/06/2025 01:45, Stefano Stabellini wrote: > >>> On Wed, 18 Jun 2025, Jan Beulich wrote: > >>>> On 18.06.2025 02:39, Stefano Stabellini wrote: > >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote: > >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote: > >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote: > >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote: > >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: > >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote: > >>>>>>>>>>> From: Denis Mukhin <dmukhin@ford.com> > >>>>> If I understood correctly I like your proposal. Let me rephrase it to > >>>>> make sure we are aligned. You are suggesting that: > >>>>> > >>>>> - domains without input focus will print with a (d<N>) prefix > >>>>> - the domain with input focus will print without a (d<N>) prefix > >>>>> - this applies to both DomUs and Dom0 > >>>> > >>>> Except in the non-dom0less case, at least up and until there's at least > >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today, > >>>> regardless of the presence of e.g. "conswitch=". > >>> > >>> In the non-dom0less case, since dom0 has focus, it would naturally be > >>> without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I > >>> wouldn't special-case conswitch= that way and would prefer keep things > >>> simple and consistent without corner cases. I don't think conswitch= is > >>> so widely used that it is worth the complexity to special-case it. > >> > >> I am a bit confused with the wording. Before I can provide another opinion, I > >> want to understand a bit more the concern. > >> > >> From my understanding the command line option "conswitch" is to allow the > >> admin to change with key is used to switch between Dom0 and Xen. By default > >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to > >> dom0 console) can be added? > > > > Yes, conswitch can also be used to ask Xen to keep the input focus to > > itself, instead of giving it away to Dom0. I think this is the specific > > feature Jan was referring to when he said he is using conswitch and the > > proposal would change the way the output looks like for him, which is > > true. > > > > Today, dom0 would still print without any prefix. > > > > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix > > because it doesn't have input focus. > > > > The question is, with the new policy in place, whether this is worth the > > trouble of having a special case to remove the "(d0)" prefix in the > > conswitch=x case. I think it is not worth it, Jan thinks it is. > > Just to clarify: Along with this mode being entered by conswitch=, I also > expect the behavior to remain unaltered when booting (non-dom0less) > without that option, and later flipping focus between Xen and Dom0 by > using triple Ctrl-a. I'm saying this just to make sure that an eventual > change to the patch wouldn't be keyed to the use of the command line > option. I will preserve the existing non-dom0less dom0 behavior for printouts. Thanks for the patience and the feedback! > > Jan
On Sun, 28 Jun 2025, Jan Beulich wrote: > On 27.06.2025 23:58, Stefano Stabellini wrote: > > On Fri, 27 Jun 2025, Julien Grall wrote: > >> Hi Stefano, > >> > >> On 19/06/2025 01:45, Stefano Stabellini wrote: > >>> On Wed, 18 Jun 2025, Jan Beulich wrote: > >>>> On 18.06.2025 02:39, Stefano Stabellini wrote: > >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote: > >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote: > >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote: > >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote: > >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: > >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote: > >>>>>>>>>>> From: Denis Mukhin <dmukhin@ford.com> > >>>>> If I understood correctly I like your proposal. Let me rephrase it to > >>>>> make sure we are aligned. You are suggesting that: > >>>>> > >>>>> - domains without input focus will print with a (d<N>) prefix > >>>>> - the domain with input focus will print without a (d<N>) prefix > >>>>> - this applies to both DomUs and Dom0 > >>>> > >>>> Except in the non-dom0less case, at least up and until there's at least > >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today, > >>>> regardless of the presence of e.g. "conswitch=". > >>> > >>> In the non-dom0less case, since dom0 has focus, it would naturally be > >>> without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I > >>> wouldn't special-case conswitch= that way and would prefer keep things > >>> simple and consistent without corner cases. I don't think conswitch= is > >>> so widely used that it is worth the complexity to special-case it. > >> > >> I am a bit confused with the wording. Before I can provide another opinion, I > >> want to understand a bit more the concern. > >> > >> From my understanding the command line option "conswitch" is to allow the > >> admin to change with key is used to switch between Dom0 and Xen. By default > >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to > >> dom0 console) can be added? > > > > Yes, conswitch can also be used to ask Xen to keep the input focus to > > itself, instead of giving it away to Dom0. I think this is the specific > > feature Jan was referring to when he said he is using conswitch and the > > proposal would change the way the output looks like for him, which is > > true. > > > > Today, dom0 would still print without any prefix. > > > > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix > > because it doesn't have input focus. > > > > The question is, with the new policy in place, whether this is worth the > > trouble of having a special case to remove the "(d0)" prefix in the > > conswitch=x case. I think it is not worth it, Jan thinks it is. > > Just to clarify: Along with this mode being entered by conswitch=, I also > expect the behavior to remain unaltered when booting (non-dom0less) > without that option, and later flipping focus between Xen and Dom0 by > using triple Ctrl-a. I'm saying this just to make sure that an eventual > change to the patch wouldn't be keyed to the use of the command line > option. Oh, I see now where the difference of opinion lies. This is the policy as written above: - domains without input focus will print with a (d<N>) prefix - the domain with input focus will print without a (d<N>) prefix - this applies to both DomUs and Dom0 Which means that when you move around with Ctrl-AAA or conswitch, no matter if it is dom0less or not, Dom0 would end up printing the prefix (d0). Jan, and now also Julien are saying that prefer to retain the old behavior. I defer to the will of the majority. So then the policy would be: Dom0less: - domains without input focus will print with a (d<N>) prefix - the domain with input focus will print without a (d<N>) prefix - this applies to both DomUs and Dom0 Dom0: - same as today - the domain with input focus will print without a (d<N>) prefix
On Mon, 30 Jun 2025, Stefano Stabellini wrote: > On Sun, 28 Jun 2025, Jan Beulich wrote: > > On 27.06.2025 23:58, Stefano Stabellini wrote: > > > On Fri, 27 Jun 2025, Julien Grall wrote: > > >> Hi Stefano, > > >> > > >> On 19/06/2025 01:45, Stefano Stabellini wrote: > > >>> On Wed, 18 Jun 2025, Jan Beulich wrote: > > >>>> On 18.06.2025 02:39, Stefano Stabellini wrote: > > >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote: > > >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote: > > >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote: > > >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote: > > >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: > > >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote: > > >>>>>>>>>>> From: Denis Mukhin <dmukhin@ford.com> > > >>>>> If I understood correctly I like your proposal. Let me rephrase it to > > >>>>> make sure we are aligned. You are suggesting that: > > >>>>> > > >>>>> - domains without input focus will print with a (d<N>) prefix > > >>>>> - the domain with input focus will print without a (d<N>) prefix > > >>>>> - this applies to both DomUs and Dom0 > > >>>> > > >>>> Except in the non-dom0less case, at least up and until there's at least > > >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today, > > >>>> regardless of the presence of e.g. "conswitch=". > > >>> > > >>> In the non-dom0less case, since dom0 has focus, it would naturally be > > >>> without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I > > >>> wouldn't special-case conswitch= that way and would prefer keep things > > >>> simple and consistent without corner cases. I don't think conswitch= is > > >>> so widely used that it is worth the complexity to special-case it. > > >> > > >> I am a bit confused with the wording. Before I can provide another opinion, I > > >> want to understand a bit more the concern. > > >> > > >> From my understanding the command line option "conswitch" is to allow the > > >> admin to change with key is used to switch between Dom0 and Xen. By default > > >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to > > >> dom0 console) can be added? > > > > > > Yes, conswitch can also be used to ask Xen to keep the input focus to > > > itself, instead of giving it away to Dom0. I think this is the specific > > > feature Jan was referring to when he said he is using conswitch and the > > > proposal would change the way the output looks like for him, which is > > > true. > > > > > > Today, dom0 would still print without any prefix. > > > > > > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix > > > because it doesn't have input focus. > > > > > > The question is, with the new policy in place, whether this is worth the > > > trouble of having a special case to remove the "(d0)" prefix in the > > > conswitch=x case. I think it is not worth it, Jan thinks it is. > > > > Just to clarify: Along with this mode being entered by conswitch=, I also > > expect the behavior to remain unaltered when booting (non-dom0less) > > without that option, and later flipping focus between Xen and Dom0 by > > using triple Ctrl-a. I'm saying this just to make sure that an eventual > > change to the patch wouldn't be keyed to the use of the command line > > option. > > Oh, I see now where the difference of opinion lies. This is the policy > as written above: > > - domains without input focus will print with a (d<N>) prefix > - the domain with input focus will print without a (d<N>) prefix > - this applies to both DomUs and Dom0 > > Which means that when you move around with Ctrl-AAA or conswitch, no > matter if it is dom0less or not, Dom0 would end up printing the prefix > (d0). > > Jan, and now also Julien are saying that prefer to retain the old > behavior. I defer to the will of the majority. So then the policy would > be: > > Dom0less: > - domains without input focus will print with a (d<N>) prefix > - the domain with input focus will print without a (d<N>) prefix > - this applies to both DomUs and Dom0 > > Dom0: > - same as today > - the domain with input focus will print without a (d<N>) prefix Sorry this last line was an editing error. I'll write it again for clarity. Dom0less: - domains without input focus will print with a (d<N>) prefix - the domain with input focus will print without a (d<N>) prefix - this applies to both DomUs and Dom0 Dom0: - same as today (with or without conswitch)
On Mon, Jun 30, 2025 at 03:27:32PM -0700, Stefano Stabellini wrote: > On Mon, 30 Jun 2025, Stefano Stabellini wrote: > > On Sun, 28 Jun 2025, Jan Beulich wrote: > > > On 27.06.2025 23:58, Stefano Stabellini wrote: > > > > On Fri, 27 Jun 2025, Julien Grall wrote: > > > >> Hi Stefano, > > > >> > > > >> On 19/06/2025 01:45, Stefano Stabellini wrote: > > > >>> On Wed, 18 Jun 2025, Jan Beulich wrote: > > > >>>> On 18.06.2025 02:39, Stefano Stabellini wrote: > > > >>>>> On Thu, 12 Jun 2025, Jan Beulich wrote: > > > >>>>>> On 11.06.2025 21:07, Stefano Stabellini wrote: > > > >>>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote: > > > >>>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote: > > > >>>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: > > > >>>>>>>>>> On 06.06.2025 22:11, dmkhn@proton.me wrote: > > > >>>>>>>>>>> From: Denis Mukhin <dmukhin@ford.com> > > > >>>>> If I understood correctly I like your proposal. Let me rephrase it to > > > >>>>> make sure we are aligned. You are suggesting that: > > > >>>>> > > > >>>>> - domains without input focus will print with a (d<N>) prefix > > > >>>>> - the domain with input focus will print without a (d<N>) prefix > > > >>>>> - this applies to both DomUs and Dom0 > > > >>>> > > > >>>> Except in the non-dom0less case, at least up and until there's at least > > > >>>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today, > > > >>>> regardless of the presence of e.g. "conswitch=". > > > >>> > > > >>> In the non-dom0less case, since dom0 has focus, it would naturally be > > > >>> without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I > > > >>> wouldn't special-case conswitch= that way and would prefer keep things > > > >>> simple and consistent without corner cases. I don't think conswitch= is > > > >>> so widely used that it is worth the complexity to special-case it. > > > >> > > > >> I am a bit confused with the wording. Before I can provide another opinion, I > > > >> want to understand a bit more the concern. > > > >> > > > >> From my understanding the command line option "conswitch" is to allow the > > > >> admin to change with key is used to switch between Dom0 and Xen. By default > > > >> this is 'a'. So are you referring to the fact a trailing "x" (to not switch to > > > >> dom0 console) can be added? > > > > > > > > Yes, conswitch can also be used to ask Xen to keep the input focus to > > > > itself, instead of giving it away to Dom0. I think this is the specific > > > > feature Jan was referring to when he said he is using conswitch and the > > > > proposal would change the way the output looks like for him, which is > > > > true. > > > > > > > > Today, dom0 would still print without any prefix. > > > > > > > > Tomorrow with this proposal, dom0 would print with a "(d0)" prefix > > > > because it doesn't have input focus. > > > > > > > > The question is, with the new policy in place, whether this is worth the > > > > trouble of having a special case to remove the "(d0)" prefix in the > > > > conswitch=x case. I think it is not worth it, Jan thinks it is. > > > > > > Just to clarify: Along with this mode being entered by conswitch=, I also > > > expect the behavior to remain unaltered when booting (non-dom0less) > > > without that option, and later flipping focus between Xen and Dom0 by > > > using triple Ctrl-a. I'm saying this just to make sure that an eventual > > > change to the patch wouldn't be keyed to the use of the command line > > > option. > > > > Oh, I see now where the difference of opinion lies. This is the policy > > as written above: > > > > - domains without input focus will print with a (d<N>) prefix > > - the domain with input focus will print without a (d<N>) prefix > > - this applies to both DomUs and Dom0 > > > > Which means that when you move around with Ctrl-AAA or conswitch, no > > matter if it is dom0less or not, Dom0 would end up printing the prefix > > (d0). > > > > Jan, and now also Julien are saying that prefer to retain the old > > behavior. I defer to the will of the majority. So then the policy would > > be: > > > > Dom0less: > > - domains without input focus will print with a (d<N>) prefix > > - the domain with input focus will print without a (d<N>) prefix > > - this applies to both DomUs and Dom0 > > > > Dom0: > > - same as today > > - the domain with input focus will print without a (d<N>) prefix > > Sorry this last line was an editing error. I'll write it again for > clarity. > > Dom0less: > - domains without input focus will print with a (d<N>) prefix > - the domain with input focus will print without a (d<N>) prefix > - this applies to both DomUs and Dom0 > > Dom0: > - same as today (with or without conswitch) Thanks! >
On 19.06.2025 02:45, Stefano Stabellini wrote:
> On Wed, 18 Jun 2025, Jan Beulich wrote:
>> On 18.06.2025 02:39, Stefano Stabellini wrote:
>>> On Thu, 12 Jun 2025, Jan Beulich wrote:
>>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
>>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
>>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
>>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
>>>>>>>> On 06.06.2025 22:11, 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)".
>>>>>>>>
>>>>>>>> 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.
>>>>>
>>>>> If we only consider the classic dom0 and dom0less usage models, then
>>>>> what you wrote makes perfect sense. In the classic dom0 case, it is best
>>>>> for dom0 to have no prefix, which is the current behavior.
>>>>>
>>>>> However, things become more complex with dom0less. As we have discussed
>>>>> previously, it has already become desirable on both ARM and x86 to align
>>>>> on the same behavior. During our last discussion, the preference was to
>>>>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
>>>>> domains.
>>>>>
>>>>> Up to now, we could easily detect the two different cases depending on
>>>>> the boot configuration. The problem arises with Denis' patches, which
>>>>> add the ability for dynamically created guests via `xl` to access an
>>>>> emulated NS16550 UART that prints to the console. Because these guests
>>>>> are created dynamically, it is not clear how we are going to handle
>>>>> this case.
>>>>
>>>> Why would this be not clear? We already prefix their output with "(d<N>)"
>>>> when going the traditional way. The same would then apply to output
>>>> coming through the emulated UART.
>>>>
>>>>> If we follow the dom0less preference, then we would need a '(d0)' prefix
>>>>> for dom0. If we follow the classic dom0 model, then dom0 would remain
>>>>> without a prefix, and the new domUs would have a prefix. This would
>>>>> cause an inconsistency. However, this is what we have today on ARM with
>>>>> dom0less.
>>>>>
>>>>> If Jan feels strongly that we should retain no prefix for the classic
>>>>> dom0 case, which is understandable, then I believe the best course of
>>>>> action would be to change our stance on dom0less on both ARM and x86 and
>>>>> also use no prefix for dom0 in the dom0less case (which is the current
>>>>> state on ARM).
>>>>
>>>> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
>>>> I disagree. Present behavior of not prefixing the domain's output which
>>>> has input focus continues to make sense. That requires Dom0 to have a
>>>> prefix whenever it doesn't have input focus.
>>>
>>> If I understood correctly I like your proposal. Let me rephrase it to
>>> make sure we are aligned. You are suggesting that:
>>>
>>> - domains without input focus will print with a (d<N>) prefix
>>> - the domain with input focus will print without a (d<N>) prefix
>>> - this applies to both DomUs and Dom0
>>
>> Except in the non-dom0less case, at least up and until there's at least
>> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
>> regardless of the presence of e.g. "conswitch=".
>
> In the non-dom0less case, since dom0 has focus, it would naturally be
> without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I
> wouldn't special-case conswitch= that way and would prefer keep things
> simple and consistent without corner cases. I don't think conswitch= is
> so widely used that it is worth the complexity to special-case it.
Widely used or not - _I_ use it all the time in debug configs where serial
is available.
Jan
On Fri, 20 Jun 2025, Jan Beulich wrote:
> On 19.06.2025 02:45, Stefano Stabellini wrote:
> > On Wed, 18 Jun 2025, Jan Beulich wrote:
> >> On 18.06.2025 02:39, Stefano Stabellini wrote:
> >>> On Thu, 12 Jun 2025, Jan Beulich wrote:
> >>>> On 11.06.2025 21:07, Stefano Stabellini wrote:
> >>>>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> >>>>>> On 11.06.2025 02:07, dmkhn@proton.me wrote:
> >>>>>>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote:
> >>>>>>>> On 06.06.2025 22:11, 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)".
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>
> >>>>> If we only consider the classic dom0 and dom0less usage models, then
> >>>>> what you wrote makes perfect sense. In the classic dom0 case, it is best
> >>>>> for dom0 to have no prefix, which is the current behavior.
> >>>>>
> >>>>> However, things become more complex with dom0less. As we have discussed
> >>>>> previously, it has already become desirable on both ARM and x86 to align
> >>>>> on the same behavior. During our last discussion, the preference was to
> >>>>> add a '(d0)' prefix to clearly differentiate output from dom0 and other
> >>>>> domains.
> >>>>>
> >>>>> Up to now, we could easily detect the two different cases depending on
> >>>>> the boot configuration. The problem arises with Denis' patches, which
> >>>>> add the ability for dynamically created guests via `xl` to access an
> >>>>> emulated NS16550 UART that prints to the console. Because these guests
> >>>>> are created dynamically, it is not clear how we are going to handle
> >>>>> this case.
> >>>>
> >>>> Why would this be not clear? We already prefix their output with "(d<N>)"
> >>>> when going the traditional way. The same would then apply to output
> >>>> coming through the emulated UART.
> >>>>
> >>>>> If we follow the dom0less preference, then we would need a '(d0)' prefix
> >>>>> for dom0. If we follow the classic dom0 model, then dom0 would remain
> >>>>> without a prefix, and the new domUs would have a prefix. This would
> >>>>> cause an inconsistency. However, this is what we have today on ARM with
> >>>>> dom0less.
> >>>>>
> >>>>> If Jan feels strongly that we should retain no prefix for the classic
> >>>>> dom0 case, which is understandable, then I believe the best course of
> >>>>> action would be to change our stance on dom0less on both ARM and x86 and
> >>>>> also use no prefix for dom0 in the dom0less case (which is the current
> >>>>> state on ARM).
> >>>>
> >>>> Leaving aside that "dom0 in the dom0less" ought to really be not-a-thing,
> >>>> I disagree. Present behavior of not prefixing the domain's output which
> >>>> has input focus continues to make sense. That requires Dom0 to have a
> >>>> prefix whenever it doesn't have input focus.
> >>>
> >>> If I understood correctly I like your proposal. Let me rephrase it to
> >>> make sure we are aligned. You are suggesting that:
> >>>
> >>> - domains without input focus will print with a (d<N>) prefix
> >>> - the domain with input focus will print without a (d<N>) prefix
> >>> - this applies to both DomUs and Dom0
> >>
> >> Except in the non-dom0less case, at least up and until there's at least
> >> one other domain. I.e. I'd like to keep Dom0 boot output as it is today,
> >> regardless of the presence of e.g. "conswitch=".
> >
> > In the non-dom0less case, since dom0 has focus, it would naturally be
> > without (d<N>) prefix. Unless the user passes "conswitch=". Honestly, I
> > wouldn't special-case conswitch= that way and would prefer keep things
> > simple and consistent without corner cases. I don't think conswitch= is
> > so widely used that it is worth the complexity to special-case it.
>
> Widely used or not - _I_ use it all the time in debug configs where serial
> is available.
Fair enough and your usage is really important for the project. At the
same time you know exactly what's going on so you wouldn't be confused
by the presence or absence of a (d0) prefix.
The main issue is when less familiar users try Xen, or less familiar
developers go through the Xen source code to learn from it.
I would optimize this choice to make it simpler for users and to make
the code simpler. Your use-case is really important as well, but I would
trust you to understand what's going on either way, with or without the
(d0) prefix.
I won't insist though.
Cheers,
Stefano
Hi Stefano, On 21/06/2025 01:52, Stefano Stabellini wrote: >> Widely used or not - _I_ use it all the time in debug configs where serial >> is available. > > Fair enough and your usage is really important for the project. At the > same time you know exactly what's going on so you wouldn't be confused > by the presence or absence of a (d0) prefix. > > The main issue is when less familiar users try Xen, or less familiar > developers go through the Xen source code to learn from it. > > I would optimize this choice to make it simpler for users and to make > the code simpler. Your use-case is really important as well, but I would > trust you to understand what's going on either way, with or without the > (d0) prefix. Thanks for the clarification. I gave a try with and without the series to understand a bit more the difference. I think there are some imbalance in that setup because when the focus is on Xen, the logs are still prefixed with "(XEN)". So naturally the log with no prefix are the one for Dom0. So I have to agree with Jan here. I haven't tried the behavior with dom0less. So I am not sure what would happen if the focus switch to Xen. Also, when switching focus, I have noticed a very odd behavior with this patch. "(d0)" is printed multiple time per line: " (d0) [ 1.344020] v(d0) gaarb: loaded (d0) [ 1.352808] c(d0) locksource: Swit(d0) ched to clocksou(d0) rce arch_sys_cou(d0) nter (d0) [ 1.367604] V(d0) FS: Disk quotas (d0) dquot_6.6.0 (d0) [ 1.369369] V(d0) FS: Dquot-cache (d0) hash table entri(d0) es: 512 (order 0(d0) , 4096 bytes) (d0) [ 1.376766] p(d0) np: PnP ACPI: di(d0) sabled (d0) [ 1.619730] N(d0) ET: Registered P(d0) F_INET protocol (d0) family (d0) [ 1.623635] I(d0) P idents hash ta(d0) ble entries: 163(d0) 84 (order: 5, 13(d0) 1072 bytes, line(d0) ar) (d0) [ 1.636915] t(d0) cp_listen_portad(d0) dr_hash hash tab(d0) le entries: 512 (d0) (order: 3, 36864(d0) bytes, linear) (d0) [ 1.638331] T(d0) able-perturb has(d0) h table entries:(d0) 65536 (order: 6(d0) , 262144 bytes, (d0) linear) (d0) [ 1.639267] T(d0) CP established h(d0) ash table entrie(d0) s: 8192 (order: (d0) 4, 65536 bytes, (d0) linear) (d0) [ 1.643457] T(d0) CP bind hash tab(d0) le entries: 8192(d0) (order: 8, 1179(d0) 648 bytes, linea(d0) r) (d0) [ 1.652078] T(d0) CP: Hash tables (d0) configured (esta(d0) blished 8192 bin(d0) d 8192) (d0) [ 1.655824] U(d0) DP hash table en(d0) tries: 512 (orde(d0) r: 4, 81920 byte(d0) s, linear) (d0) [ 1.657807] U(d0) DP-Lite hash tab(d0) le entries: 512 (d0) (order: 4, 81920(d0) bytes, linear) (d0) [ 1.661993] N(d0) ET: Registered P(d0) F_UNIX/PF_LOCAL (d0) protocol family (d0) [ 1.674980] R(d0) PC: Registered n(d0) amed UNIX socket(d0) transport modul(d0) e. (d0) [ 1.676034] R(d0) PC: Registered u(d0) dp transport mod(d0) ule. (d0) [ 1.677241] R(d0) PC: Registered t(d0) cp transport mod(d0) ule. (d0) [ 1.677964] R(d0) PC: Registered t(d0) cp-with-tls tran(d0) sport module. (d0) [ 1.678615] R(d0) PC: Registered t(d0) cp NFSv4.1 backc(d0) hannel transport(d0) module. " Cheers, -- Julien Grall
On Sat, Jun 28, 2025 at 06:26:12PM +0100, Julien Grall wrote: > Hi Stefano, > > On 21/06/2025 01:52, Stefano Stabellini wrote: > >> Widely used or not - _I_ use it all the time in debug configs where serial > >> is available. > > > > Fair enough and your usage is really important for the project. At the > > same time you know exactly what's going on so you wouldn't be confused > > by the presence or absence of a (d0) prefix. > > > > The main issue is when less familiar users try Xen, or less familiar > > developers go through the Xen source code to learn from it. > > > > I would optimize this choice to make it simpler for users and to make > > the code simpler. Your use-case is really important as well, but I would > > trust you to understand what's going on either way, with or without the > > (d0) prefix. > > Thanks for the clarification. I gave a try with and without the series > to understand a bit more the difference. I think there are some > imbalance in that setup because when the focus is on Xen, the logs are > still prefixed with "(XEN)". So naturally the log with no prefix are the > one for Dom0. So I have to agree with Jan here. > > I haven't tried the behavior with dom0less. So I am not sure what would > happen if the focus switch to Xen. > > Also, when switching focus, I have noticed a very odd behavior with this > patch. "(d0)" is printed multiple time per line: Thanks for catching this, will fix. > > " > (d0) [ 1.344020] v(d0) gaarb: loaded > (d0) [ 1.352808] c(d0) locksource: Swit(d0) ched to clocksou(d0) rce > arch_sys_cou(d0) nter > (d0) [ 1.367604] V(d0) FS: Disk quotas (d0) dquot_6.6.0 > (d0) [ 1.369369] V(d0) FS: Dquot-cache (d0) hash table entri(d0) es: > 512 (order 0(d0) , 4096 bytes) > (d0) [ 1.376766] p(d0) np: PnP ACPI: di(d0) sabled > (d0) [ 1.619730] N(d0) ET: Registered P(d0) F_INET protocol (d0) family > (d0) [ 1.623635] I(d0) P idents hash ta(d0) ble entries: 163(d0) 84 > (order: 5, 13(d0) 1072 bytes, line(d0) ar) > (d0) [ 1.636915] t(d0) cp_listen_portad(d0) dr_hash hash tab(d0) le > entries: 512 (d0) (order: 3, 36864(d0) bytes, linear) > (d0) [ 1.638331] T(d0) able-perturb has(d0) h table entries:(d0) > 65536 (order: 6(d0) , 262144 bytes, (d0) linear) > (d0) [ 1.639267] T(d0) CP established h(d0) ash table entrie(d0) s: > 8192 (order: (d0) 4, 65536 bytes, (d0) linear) > (d0) [ 1.643457] T(d0) CP bind hash tab(d0) le entries: 8192(d0) > (order: 8, 1179(d0) 648 bytes, linea(d0) r) > (d0) [ 1.652078] T(d0) CP: Hash tables (d0) configured (esta(d0) > blished 8192 bin(d0) d 8192) > (d0) [ 1.655824] U(d0) DP hash table en(d0) tries: 512 (orde(d0) r: > 4, 81920 byte(d0) s, linear) > (d0) [ 1.657807] U(d0) DP-Lite hash tab(d0) le entries: 512 (d0) > (order: 4, 81920(d0) bytes, linear) > (d0) [ 1.661993] N(d0) ET: Registered P(d0) F_UNIX/PF_LOCAL (d0) > protocol family > (d0) [ 1.674980] R(d0) PC: Registered n(d0) amed UNIX socket(d0) > transport modul(d0) e. > (d0) [ 1.676034] R(d0) PC: Registered u(d0) dp transport mod(d0) ule. > (d0) [ 1.677241] R(d0) PC: Registered t(d0) cp transport mod(d0) ule. > (d0) [ 1.677964] R(d0) PC: Registered t(d0) cp-with-tls tran(d0) > sport module. > (d0) [ 1.678615] R(d0) PC: Registered t(d0) cp NFSv4.1 backc(d0) > hannel transport(d0) module. > " > > Cheers, > > -- > Julien Grall > >
On 28/06/2025 18:26, Julien Grall wrote: > Hi Stefano, > > On 21/06/2025 01:52, Stefano Stabellini wrote: >>> Widely used or not - _I_ use it all the time in debug configs where >>> serial >>> is available. >> >> Fair enough and your usage is really important for the project. At the >> same time you know exactly what's going on so you wouldn't be confused >> by the presence or absence of a (d0) prefix. >> >> The main issue is when less familiar users try Xen, or less familiar >> developers go through the Xen source code to learn from it. >> >> I would optimize this choice to make it simpler for users and to make >> the code simpler. Your use-case is really important as well, but I would >> trust you to understand what's going on either way, with or without the >> (d0) prefix. > > Thanks for the clarification. I gave a try with and without the series > to understand a bit more the difference. I think there are some > imbalance in that setup because when the focus is on Xen, the logs are > still prefixed with "(XEN)". So naturally the log with no prefix are the > one for Dom0. So I have to agree with Jan here. I forgot to clarify, this is not an ask to remove (XEN) when the focus is on Xen. This is more we should keep the existing behavior. Cheers, -- Julien Grall
© 2016 - 2025 Red Hat, Inc.