On 13.02.2026 21: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:
Quite a bit better, yet for me at least not something I would feel happy to take as a basis for an ack. > --- > > 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. XAPI at the very least would want checking here, imo. > 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()) Daniel, can you please take a look from (conceptual) XSM/Flask perspective? Jan
