All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Orzel, Michal" <michal.orzel@amd.com>
To: "Halder, Ayan Kumar" <ayankuma@amd.com>,
	<xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	<ayan.kumar.halder@amd.com>
Subject: Re: [for-4.22][PATCH] xen/arm: Fail domain construction if a secondary vCPU cannot be created
Date: Wed, 8 Jul 2026 13:20:24 +0200	[thread overview]
Message-ID: <2eabc87d-5694-4874-b204-2fe60d5368bc@amd.com> (raw)
In-Reply-To: <197f5208-b9ca-424d-a7e6-0b872e6511f1@amd.com>



On 08-Jul-26 11:06, Halder, Ayan Kumar wrote:
> Hi MIchal,
> 
> Nice catch. Few questions.
> 
> On 08/07/2026 08:49, 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 constructed
>> with fewer vCPUs than d->max_vcpus, leaving NULL holes in d->vcpu[]
>> below max_vcpus.
>>
>> When the guest probes the redistributor of a vCPU that was never created,
> Shouldn't the guest check how many vCPUs were created and probe the ones 
> that were created ?
See below about DTB.

>> get_vcpu_from_rdist() only checks vcpu_id against d->max_vcpus and then
>> dereferences the NULL d->vcpu[vcpu_id], resulting in a data abort.
>>
>> 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, which is the correct
>> behaviour: a domain that cannot provide the requested number of vCPUs
>> should not be brought up.
> 
> I see your reasoning.
> 
> Alternatively it can be a design choice. Xen does not commit to create 
> the max_vcpus that was requested.
Everything can be a design choice but this one wouldn't be wise, would it?
All in all, we (Arm maintainers) aim at following the contract to fail as soon
as possible if the user request cannot be satisfied.

> 
> If Xen is unable to create any vCPU, it should abort domain creation.
> 
> If Xen creates lesser number of vCPUs than requested by max_vcpus, it 
> can just print a warning and carry on.
No. Xen creates domain DTB before creating vCPUs, so Xen advertises something
that is not true. Here, Xen would create a DTB with e.g. 2 vCPUs while only 1
was created.

~Michal

> 
> In that case it should be the guest's responsibility to check the number 
> of CPUs that it has.
> 
> - Ayan
> 
>>
>> Fixes: 6b0e8e43348a ("xen/arm: allocate secondaries dom0 vcpus")
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>> ---
>>   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..b46574fd32aa 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 -EINVAL;
>>           }
>>   
>>           if ( is_64bit_domain(d) )



  reply	other threads:[~2026-07-08 11:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08  7:49 [for-4.22][PATCH] xen/arm: Fail domain construction if a secondary vCPU cannot be created Michal Orzel
2026-07-08  9:06 ` Halder, Ayan Kumar
2026-07-08 11:20   ` Orzel, Michal [this message]
2026-07-08 11:27     ` Halder, Ayan Kumar
2026-07-08 11:31       ` Orzel, Michal
2026-07-08  9:18 ` Dmytro Prokopchuk1
2026-07-08 11:56   ` Orzel, Michal
2026-07-08 11:30 ` Andrew Cooper
2026-07-08 11:40   ` Orzel, Michal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2eabc87d-5694-4874-b204-2fe60d5368bc@amd.com \
    --to=michal.orzel@amd.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=ayan.kumar.halder@amd.com \
    --cc=ayankuma@amd.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.