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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

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