From: sashiko-bot@kernel.org
To: "fuqiang wang" <fuqiang.wng@gmail.com>
Cc: "Oliver Upton" <oupton@kernel.org>,
kvmarm@lists.linux.dev, "Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH 1/2] arm64: Add MIDR_EL1 RES1 definitions
Date: Thu, 11 Jun 2026 09:18:39 +0000 [thread overview]
Message-ID: <20260611091840.BA79B1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260611090934.84469-2-fuqiang.wng@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The macro `MIDR_RES1_MASK` is defined as `(1 << 31)`, which causes undefined behavior via signed integer overflow and dangerous sign-extension when applied to 64-bit values.
- [High] The commit incorrectly asserts that bit 31 of `MIDR_EL1` is `RES1`. Bit 31 is actually part of the `Implementor` field.
--
commit 8b397f704d83868070b0e6c30f4a5f7c1b4f12e3
Author: fuqiang wang <fuqiang.wng@gmail.com>
arm64: Add MIDR_EL1 RES1 definitions
This patch adds definitions for bit 31 of MIDR_EL1, identifying it as a
RES1 bit.
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -39,6 +39,8 @@
> #define MIDR_IMPLEMENTOR_MASK (0xffU << MIDR_IMPLEMENTOR_SHIFT)
> #define MIDR_IMPLEMENTOR(midr) \
> (((midr) & MIDR_IMPLEMENTOR_MASK) >> MIDR_IMPLEMENTOR_SHIFT)
> +#define MIDR_RES1_SHIFT 31
[Severity: High]
Does this correctly identify the register?
According to the ARM Architecture Reference Manual, bits [31:24] of MIDR_EL1
represent the 8-bit Implementor code.
Could this be confusing MIDR_EL1 with MPIDR_EL1, where bit 31 is indeed
RES1?
> +#define MIDR_RES1_MASK (1 << MIDR_RES1_SHIFT)
[Severity: Critical]
Can this cause undefined behavior via signed integer overflow?
The literal 1 is a 32-bit signed integer, so shifting it by 31 overflows.
When this mask is used in kvm_vcpu_mpidr_is_reset(u64 val), it is
sign-extended to a 64-bit value (0xffffffff80000000). The condition
(val & MIDR_RES1_MASK) == MIDR_RES1_MASK would then expect all upper 33 bits
of val to be 1.
Since val is obtained from kvm_vcpu_get_mpidr_aff() which explicitly masks
the register value with MPIDR_HWID_BITMASK and clears bit 31,
kvm_vcpu_mpidr_is_reset() will always evaluate to false.
Will this cause kvm_init_mpidr_data() to unconditionally skip all vCPUs,
leaving the KVM MPIDR-to-vCPU lookup table empty and guests unbootable?
>
> #define MIDR_CPU_MODEL(imp, partnum) \
> ((_AT(u32, imp) << MIDR_IMPLEMENTOR_SHIFT) | \
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611090934.84469-1-fuqiang.wng@gmail.com?part=1
next prev parent reply other threads:[~2026-06-11 9:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 9:09 [PATCH 0/2] KVM: arm64: Fix MPIDR lookup for unreset vCPUs fuqiang wang
2026-06-11 9:09 ` [PATCH 1/2] arm64: Add MIDR_EL1 RES1 definitions fuqiang wang
2026-06-11 9:18 ` sashiko-bot [this message]
2026-06-11 9:09 ` [PATCH 2/2] KVM: arm64: Skip unreset vCPUs in MPIDR lookup table fuqiang wang
2026-06-11 9:28 ` sashiko-bot
2026-06-11 10:23 ` fuqiang wang
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=20260611091840.BA79B1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fuqiang.wng@gmail.com \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.