On 18.02.2026 16:07, Daniel P. Smith wrote: > 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.
I don't think I can deduce from this what your view is on the change proposed. There is, as per what you say, an existing issue with is_hardware_domain(). (Likely at some point you'll propose patches to address this.) What I can't conclude is whether you deem this new issue "okay(ish)" on the basis that some vaguely related issue already exists, or whether you object to this new way of "subversion". Jan
