On 2025-12-04 18:32, Grygorii Strashko wrote:
From: Grygorii Strashko <[email protected]>
When 2 or more domains are created and:
- one is hwdom with "hvc0" (console_io) console
- other DomUs with vpl011 or "hvc0" (console_io) console
console output from hwdom may mix with output from other domains.
Example:
[ 2.288816] Key type id_legacy registered
[ 2.291894] n(XEN) DOM1: [ 1.016950] DMA: preallocated 128 KiB
GFP_KERNEL|GFP_DMA32 pool for atomic allocations
fs4filelayout_init: NFSv4 File Layout Driver Registering...
(XEN) DOM1: [ 1.018846] audit: initializing netlink subsys (disabled)
This happens because for hwdom the console output is produced by domain and
handled by Xen as stream of chars, which can be interrupted when hwdom is
scheduled out and so, cause console output mix.
The Xen consoleio code trying to mimic serial HW behavior for hwdom
unconditionally by sending available data to serial HW on arrival.
Xen consoleio code does not account for Xen console input focus, comparing
to emulated serial hw, like vpl011, which does the same for domain with
active Xen console input focus only.
Switching console input focus to Xen improves situation, but not enough.
This patch changes consoleio code to account for domain with active Xen
console input focus - console output will be sent directly to serial HW
only if domain has active Xen console input focus. For other domains -
console output will be buffered and sync on per-line basis.
Example output:
(d2) [ 4.263417] Key type id_legacy registered
(XEN) DOM1: [ 4.658080] Advanced Linux Sound Architecture Driver Initialized.
(d2) [ 4.277824] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
Signed-off-by: Grygorii Strashko <[email protected]>
---
This causes random multi-domain tests failures due to inter-domain console
mixing which breaks console parsing checks.
Part of the motivation here is that in a downstream, I've enabled domUs
to use the consoleio hypercalls with Hyperlunch to remove dependency on
xenconsoled. Grygorii can confirm if it also affects ARM sometimes.
xen/drivers/char/console.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index a99605103552..391cefc1a7c6 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -733,6 +733,8 @@ static long
guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
while ( count > 0 )
{
+ struct domain *input;
+
if ( kcount && hypercall_preempt_check() )
return hypercall_create_continuation(
__HYPERVISOR_console_io, "iih",
@@ -742,7 +744,9 @@ static long
guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
if ( copy_from_guest(kbuf, buffer, kcount) )
return -EFAULT;
- if ( is_hardware_domain(cd) )
+ input = console_get_domain();
+
Maybe remove this blank line?
+ if ( cd == input )
{
/* Use direct console output as it could be interactive */
nrspin_lock_irq(&console_lock);
@@ -783,6 +787,8 @@ static long
guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
In between the hunks is:
guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cons->buf, kbuf);
So a background dom0 would get a d0 prefix and print at debug level.
For ARM, vpl011_write_data_xen() does:
if ( d == input )
printk("%s", intf->out);
else
printk("DOM%u: %s", d->domain_id, intf->out);
I think d0: is okay for background printing, but we'd need to up the log
level for at least hardware domain. Maybe we want a properly to control
the level for each domain?
I think the changes made in this patch make sense.
Thanks,
Jason
spin_unlock(&cons->lock);
}
+ console_put_domain(input);
+
guest_handle_add_offset(buffer, kcount);
count -= kcount;
}
