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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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 <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())
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