Re: [PATCH v10 2/5] xen: change VIRQ_CONSOLE to VIRQ_DOMAIN to allow non-hwdom binding

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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 <jason.andryuk@xxxxxxx>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> >>
> >> 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())