On 2/13/26 15:09, Stefano Stabellini wrote:
On Tue, 10 Feb 2026, Jan Beulich wrote:
On 10.02.2026 00:23, Stefano Stabellini wrote:
On Mon, 9 Feb 2026, Jan Beulich wrote:
On 05.02.2026 00:37, Stefano Stabellini wrote:
Today only hwdom can bind VIRQ_CONSOLE. This patch changes the virq from
global to VIRQ_DOMAIN to allow other domains to bind to it.
Note that Linux silently falls back to polling when binding fails, which
masks the issue.
Signed-off-by: Jason Andryuk <[email protected]>
Signed-off-by: Stefano Stabellini <[email protected]>
Technically this is an ABI change, and hence I'm uncertain it can go without
that aspect being at least mentioned, perhaps even its implications properly
discussed.
I am not sure if it qualifies as an ABI change or not but I am happy to
expand the commit message in any way you might suggest.
The jist of it is already in the commit message, really the key element
is that VIRQ_CONSOLE can be bound by multiple domains.
Aside from spelling out "this is an ABI change" what do you have in
mind?
What I mean is discussion of the implications for domains using the vIRQ.
Previously most domains would have attempts to bind this vIRQ rejected.
Technically it is possible that kernels had code paths blindly doing the
binding, relying on it to work only when running as Dom0. And really, you
appear to break XEN_DOMCTL_set_virq_handler when used with VIRQ_CONSOLE,
without which its binding wasn't possible at all before (except for the
hardware domain, which get_global_virq_handler() falls back to when no
other domain is set). Or am I mis-reading things, as I can't spot any use
of VIRQ_CONSOLE under tools/, whereas I would have expected provisions
for (host) console handling to be delegated to a separate control or
console domain? Of course other toolstacks (the XAPI-based one for
example) might actually have such provisions.
And then there's the XSM question: XEN_DOMCTL_set_virq_handler obviously
is subject to XSM checking. The same isn't true for VIRQ_DOMAIN-type
vIRQ-s. Yet this vIRQ isn't supposed to be universally available to
every DomU. Instead the ->console->input_allowed checking is kind of
substituting such a check, which iirc Daniel said (in more general
context) shouldn't ever be done. IOW in patch 5 you're actually effecting
policy, which should be XSM's job aiui.
Bottom line: The patch may need to be more involved, but at the very
least the description would need updating to justify it being as simple
as it is right now.
What do you think of this:
---
xen/console: change VIRQ_CONSOLE from global to per-domain
Previously VIRQ_CONSOLE was a global VIRQ (VIRQ_GLOBAL type), meaning
only the hardware domain (or a domain explicitly set via
XEN_DOMCTL_set_virq_handler) could bind it. Any other domain attempting
to bind would fail with -EBUSY because get_global_virq_handler() would
return hwdom by default.
This patch changes VIRQ_CONSOLE to VIRQ_DOMAIN type, allowing any domain
to bind it independently, similar to VIRQ_ARGO. The console notification
is now sent via send_guest_domain_virq() directly to the focus domain
rather than through send_global_virq().
Implications:
1. Guest kernels that previously called bind on VIRQ_CONSOLE blindly
will now succeed. Linux handles binding failure gracefully by falling
back to polling, so this should not cause regressions.
2. XEN_DOMCTL_set_virq_handler can no longer be used with VIRQ_CONSOLE.
The domctl explicitly rejects non-VIRQ_GLOBAL types. This means
toolstacks that relied on set_virq_handler to delegate console handling
to a separate console domain will need to use a different mechanism.
Note: No known in-tree toolstack uses set_virq_handler with VIRQ_CONSOLE.
3. VIRQ_DOMAIN bindings are not subject to XSM checks beyond the
standard event channel allocation policy. Access control for console
input is enforced via the per-domain console->input_allowed flag,
which is set for:
- The hardware domain (by default in domain_create())
- dom0less domains on ARM (in construct_domU())
- The PV shim domain on x86 (in pv_shim_setup_dom())
- Domains with vpl011 using the Xen backend (in domain_vpl011_init())
Actually this goes back to the concern I have raised many times,
is_hardware_domain() always serves a double purpose. The explicit check
that the domain is where the hardware is, but also the implicit access
control check that it is allowed to do the hardware access. The implicit
access control check is a subversion of XSM and the reality is that the
input_allowed flag is just unmasking this subversion for an explicit
access control check outside the purview of xsm.
v/r,
dps
