Hi Andrew,
> On 17 May 2022, at 20:41, Andrew Cooper <andrew.coop...@citrix.com> wrote:
>
> c/s cfc52148444f ("xen/domain: Reduce the quantity of initialisation for
> system domains") removed the path in domain_create() which called
> sched_init_domain() with CPUPOOLID_NONE for system domains.
>
> Arguably, that changeset should have cleaned up this path too.
>
> However, c/s 92ea9c54fc81 ("arm/dom0less: assign dom0less guests to cpupools")
> changed domain_create() from using a hardcoded poolid of 0, to using a value
> passed by the toolstack.
>
> While CPUPOOLID_NONE is an internal constant, userspace can pass -1 for the
> cpupool_id parameter and attempt to construct a real domain using default ops,
> which at a minimum will fail the assertion in dom_scheduler().
>
> Fixes: 92ea9c54fc81 ("arm/dom0less: assign dom0less guests to cpupools")
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Thanks for this fix, with the introduction of 92ea9c54fc81 ("arm/dom0less:
assign dom0less guests to cpupools”)
we’ve checked all the path passing struct xen_domctl_createdomain, and at that
time it seems to be that
the new cpupool_id member would have been always zero when created from the
tool stack, am I wrong?
I’m asking so that I will keep in mind for the future.
However with your second patch of this serie, the tool stack is able to write
it, so I guess this fix now is mandatory.
I’ve tested your patch, enabling boot time cpupools, on an arm machine and
booting Xen+Dom0 and another DomU
by dom0less feature, and all works.
Reviewed-by: Luca Fancellu <luca.fance...@arm.com>
Tested-by: Luca Fancellu <luca.fance...@arm.com>
Cheers,
Luca
