From: "Orzel, Michal" <michal.orzel@amd.com>
To: Andrew Cooper <andrew.cooper3@citrix.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:40:27 +0200 [thread overview]
Message-ID: <e2cceffa-4f7d-4b4e-b69b-3cf11e0049ae@amd.com> (raw)
In-Reply-To: <1cce5057-3f17-4144-acc7-b343718c431f@citrix.com>
On 08-Jul-26 13:30, Andrew Cooper wrote:
> On 08/07/2026 8:49 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 constructed
>> with fewer vCPUs than d->max_vcpus, leaving NULL holes in d->vcpu[]
>> below max_vcpus.
>
> I'd suggest phrasing this as "partially constructed". "holes" isn't
> really what's going on, given the linear nature of allocation.
>
> Because of the object visibility, and because constructing vCPUs isn't
> atomic, all code needs to cope with d->vcpu[] having no, some or all of
> d->max_vcpus constructed.
>
>>
>> When the guest probes the redistributor of a vCPU that was never created,
>> 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.
>
> That's unsafe, especially as vcpu_id is calculated from an MMIO access.
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index c1c4d6f71ea8..c01cc596d593 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1111,10 +1111,10 @@ static struct vcpu *get_vcpu_from_rdist(struct
> domain *d,
> unsigned int vcpu_id;
>
> vcpu_id = region->first_cpu + ((gpa - region->base) / GICV3_GICR_SIZE);
> - if ( unlikely(vcpu_id >= d->max_vcpus) )
> - return NULL;
>
> - v = d->vcpu[vcpu_id];
> + v = domain_vcpu(d, vcpu_id);
> + if ( !v )
> + return NULL;
>
> *offset = gpa - v->arch.vgic.rdist_base;
>
>
> Do you want me to submit this separately?
If you have time, yes. Otherwise I can do that too tomorrow.
>
>
>>
>> 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.
>>
>> 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) )
>
> On x86, we explicitly tolerate a failure to build all of dom0's CPUs, if
> at least one did get constructed. This is to increase the chances that
> the server can boot and at least let an admin in to look at things.
>
> However, I can see why such a behaviour is not wanted in a "single
> pre-packaged system" as used by automotive.
Yes, that is a known difference in behavior between x86 and Arm. We decided to
bail out asap.
~Michal
prev parent reply other threads:[~2026-07-08 11:40 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
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 [this message]
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=e2cceffa-4f7d-4b4e-b69b-3cf11e0049ae@amd.com \
--to=michal.orzel@amd.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=ayan.kumar.halder@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.