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@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
Changes in v10:
- update comment in xen/include/public/xen.h
---
xen/common/event_channel.c | 1 +
xen/drivers/char/console.c | 2 +-
xen/include/public/xen.h | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a3d18bc464..f9becb4ca5 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -138,6 +138,7 @@ static enum virq_type get_virq_type(unsigned int virq)
return VIRQ_VCPU;
case VIRQ_ARGO:
+ case VIRQ_CONSOLE:
return VIRQ_DOMAIN;
case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 35f541ca8e..fbc89ca2a4 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -613,7 +613,7 @@ static void __serial_rx(char c)
* Always notify the hardware domain: prevents receive path from
* getting stuck.
*/
- send_global_virq(VIRQ_CONSOLE);
+ send_guest_domain_virq(d, VIRQ_CONSOLE);
}
#ifdef CONFIG_SBSA_VUART_CONSOLE
else
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b12fd10e63..b8146bd00a 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -176,7 +176,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
/* ` enum virq { */
#define VIRQ_TIMER 0 /* V. Timebase update, and/or requested timeout. */
#define VIRQ_DEBUG 1 /* V. Request guest to dump debug info. */
-#define VIRQ_CONSOLE 2 /* G. Bytes received on emergency console. */
+#define VIRQ_CONSOLE 2 /* D. Bytes received on Xen console. */
#define VIRQ_DOM_EXC 3 /* G. Exceptional event for some domain. */
#define VIRQ_TBUF 4 /* G. Trace buffer has records available. */
#define VIRQ_DEBUGGER 6 /* G. A domain has paused for debugging. */
--
2.25.1On 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@amd.com> > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> 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. Jan
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@amd.com> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> > > 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?
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@amd.com> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >> >> 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. Jan
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@amd.com> > >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> > >> > >> 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())
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@amd.com> >>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >>>> >>>> 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
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 <jason.andryuk@amd.com> >>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >>>>> >>>>> 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
On 2/18/26 10:14, Jan Beulich wrote: > 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 <jason.andryuk@amd.com> >>>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >>>>>> >>>>>> 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". Digging deeper, the underlying issue is that when struct domain_console was introduced and now this series is building upon it. The struct domain_console_patch added a resource access control check point for all domains through input_allowed that went around XSM. Now we are here with this series that is exposing what was done. To your question, am I okay(ish) with this. Not really, but it's also not the fault of Stefano or his series that the earlier commit laid this landmine for him. With all that said, thinking about it in totality, the fine-grained access control does needs to be there for tightly controlled environments, but is not necessary for a general security posture. Plus, I am going to have to think about how to correctly inlay the XSM check, which is outside the scope of this series. All of that is to say, I am not okay but don't feel it's right to block this series over it. v/r, dps
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 <jason.andryuk@amd.com> >>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> >>>> >>>> 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
On Wed, Feb 04, 2026 at 03:37:09PM -0800, 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@amd.com> > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Denis Mukhin <dmukhin@ford.com>
© 2016 - 2026 Red Hat, Inc.