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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan