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

[Jan Beulich <jbeulich@xxxxxxxx>]

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@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.

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