On 31.05.2025 01:19, dm...@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
> spin_unlock(&domid_lock);
> }
>
> +/*
> + * Find the ID of the next possible console owner domain.
> + *
> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> + * the range of [0..DOMID_FIRST_RESERVED-1].
> + */
> +domid_t domid_find_with_input_allowed(domid_t hint)
> +{
> + domid_t domid = DOMID_XEN;
> +
> + if ( hint < DOMID_FIRST_RESERVED )
> + {
> + struct domain *d;
> +
> + rcu_read_lock(&domlist_read_lock);
> +
> + for ( d = domid_to_domain(hint);
If the domain with ID "hint" went away, what is being switched to changes
compared to behavior prior to this patch, if I'm not mistaken. While this
_may_ be acceptable, not saying so in the description is imo a no-go.
> + d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVED;
What's the DOMID_FIRST_RESERVED check for? And where's the put_domain()
for the get_domain() here?
> + d = rcu_dereference(d->next_in_list) )
> + {
> + if ( d->console.input_allowed )
> + {
> + domid = d->domain_id;
> + break;
> + }
> + }
> +
> + rcu_read_unlock(&domlist_read_lock);
> + }
> +
> + return domid;
> +}
My concern remains: With many domains, the loop here may take quite a few
iterations. That's even more concerning because it regresses right away in
environments where along with boot-time created domains (eligible for
console focus) later further domains are created (non of which are eligible
for console focus). That is, the step from last boot-time created back to
DOMID_XEN may now take excessively long.
Jan
