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).

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@amd.com>
---
Changes in v2:
 - return ENOMEM as allocation failure is most frequent cause of failure
 - update commit msg to focus on unmet contracts
---
 xen/arch/arm/domain_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 550617f152bb..72d531618045 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1847,7 +1847,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
         if ( vcpu_create(d, i) == NULL )
         {
             printk("Failed to allocate d%dv%d\n", d->domain_id, i);
-            break;
+            return -ENOMEM;
         }
 
         if ( is_64bit_domain(d) )
-- 
2.43.0

On 7/9/26 8:36 AM, 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).
> 
> 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@amd.com>
> ---
> Changes in v2:
>   - return ENOMEM as allocation failure is most frequent cause of failure
>   - update commit msg to focus on unmet contracts
> ---
>   xen/arch/arm/domain_build.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 550617f152bb..72d531618045 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1847,7 +1847,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>           if ( vcpu_create(d, i) == NULL )
>           {
>               printk("Failed to allocate d%dv%d\n", d->domain_id, i);
> -            break;
> +            return -ENOMEM;
>           }
>   
>           if ( is_64bit_domain(d) )

Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

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@amd.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
> Changes in v2:
>   - return ENOMEM as allocation failure is most frequent cause of failure
>   - update commit msg to focus on unmet contracts
> ---
>   xen/arch/arm/domain_build.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 550617f152bb..72d531618045 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1847,7 +1847,7 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>           if ( vcpu_create(d, i) == NULL )
>           {
>               printk("Failed to allocate d%dv%d\n", d->domain_id, i);
> -            break;
> +            return -ENOMEM;
>           }
>   
>           if ( is_64bit_domain(d) )

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@amd.com>
> Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>

On 09-Jul-26 11:32, 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).
I agree and this is the reason behind this patch.
> 
>>
>> 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@amd.com>
> Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Thanks.

~Michal