Re: [for-4.22][PATCH v2] xen/arm: Fail domain construction if a secondary vCPU cannot be created

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 9 Jul 2026, Halder, Ayan Kumar wrote:
> On 09/07/2026 07:36, Michal Orzel wrote:
> > construct_domain() creates the secondary vCPUs in a loop, but on a
> > vcpu_create() failure it only prints a message and breaks out of the
> > loop returning success. As a result the domain can be partially
> > constructed with fewer vCPUs than d->max_vcpus. This causes two contract
> > violations:
> >   - Xen-Guest: domain's FDT is generated before vCPU creation - Xen exposes
> >     incorrect information (e.g. two vCPUs listed in a device tree while only
> >     one is actually created),
> >   - User-Xen: unlike x86, on Arm port we try to bail out as soon as
> >     possible on unsatisfied user requests (e.g. user requested two vCPUs
> >     for a domain but it was created with only one).
> 
> Unrelated, but just to add my 2 cents wearing a safety hat.
> 
> The user-xen contract comes from a system integrator. Xen should try to follow
> the contract and if not panic or bail out.
> 
> The Xen-guest contract can be used to enforce the rule that guest should read
> the contract before doing any safety critical task.
> 
> The most important thing is anything errors that are internal to Xen, should
> be propagated to the external world (either as panic or return an error to the
> guest or abort the guest). If there is a degradation is functionality (eg Xen
> creating a guest with lesser number of vCPUS that what the system integrator
> provided), then this is safety issue unless we put an assumption on guest to
> read its device tree and know the final configuration (which may not be always
> ok).
> 
> > 
> > Return an error instead of breaking out of the loop. Both callers
> > (construct_domU() and construct_hwdom()) already propagate a negative
> > return value and fail domain construction.
> > 
> > Fixes: 6b0e8e43348a ("xen/arm: allocate secondaries dom0 vcpus")
> > Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>

Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>