Re: [PATCH v2 2/3] arinc653: don't assume Dom0 is the control domain

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.03.2026 14:38, Jürgen Groß wrote:
> On 25.03.26 13:54, Jan Beulich wrote:
>> Leaving aside highly disaggregated environments, the control domain is
>> what will invoke XEN_SYSCTL_SCHEDOP_putinfo. Its vCPU-s therefore need to
>> be able to run unconditionally, not those of the domain with ID 0 (which
>> may not exist at all).
>>
>> Fixes: 9f0c658baedc ("arinc: add cpu-pool support to scheduler")
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Reviewed-by: Juergen Gross <jgross@xxxxxxxx>

Thanks.

>> ---
>> There being no "else" to the if(), what about other control domain vCPU-s?
> 
> a653sched_alloc_udata() is called for all units of a domain.

Yes, and what if for the last few no vacant slot is available? With one vCPU
per unit and Dom0 having 65 vCPU-s, this would already be a problem aiui.
And ARINC653_MAX_DOMAINS_PER_SCHEDULE can't even be changed easily, as it's
baked into the sysctl public header (when such an upper bound should really
be an implementation detail, maybe a Kconfig setting). Yet then even the
"DOMAINS" in the name is confusing, when it limits the number of units which
can be dealt with.

Imo at the very, very least not being able to deal with all Dom0 / ctldom
vCPU-s should be logged.

>> And why are they added to all scheduler instances?
> 
> What do you mean with "added to all scheduler instances"?
> 
> a653sched_alloc_udata() will be called only for the units of a domain being
> in the instance (i.e. cpupool) designated by the ops parameter.

Perhaps the question is a result of me being confused. My understanding was
that a653sched_alloc_udata() is supposed to be setting up per-unit data,
not per-scheduler instance stuff. Yet the latter is what looks to be
happening in the Dom0 (now control-domain) specific block of code.

Jan