From: Dmytro Maluka <dmaluka@chromium.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Mathias Krause <minipli@grsecurity.net>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
Vineeth Pillai <vineeth@bitbyteword.org>,
Chuanxiao Dong <chuanxiao.dong@intel.com>,
Aashish Sharma <aashish@aashishsharma.net>,
Grzegorz Jaszczyk <jaszczyk@chromium.org>,
Dmytro Maluka <dmaluka@chromium.org>
Subject: [PATCH 1/3] KVM: selftests: Fix treating KVM_CAP_MAX_VCPU_ID as inclusive
Date: Thu, 30 Jul 2026 18:24:23 +0000 [thread overview]
Message-ID: <20260730182425.1223530-2-dmaluka@chromium.org> (raw)
In-Reply-To: <20260730182425.1223530-1-dmaluka@chromium.org>
KVM_CAP_MAX_VCPU_ID is (confusingly) exclusive, i.e. the maximum allowed
vcpu_id value is KVM_CAP_MAX_VCPU_ID minus one.
Some tests in x86/max_vcpuid_cap_test.c and kvm/x86/set_boot_cpu_id.c
mistakenly treat it as inclusive, in particular, assume that setting
bsp_vcpu_id to KVM_CAP_MAX_VCPU_ID is valid and should succeed. Fix
those tests.
Fixes: 4b451a57809c ("KVM: selftests: Test max vCPU IDs corner cases")
Fixes: 438a496b9041 ("KVM: selftests: Test vCPU boot IDs above 2^32 and MAX_VCPU_ID")
Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
---
.../selftests/kvm/x86/max_vcpuid_cap_test.c | 17 ++++++++++-------
.../testing/selftests/kvm/x86/set_boot_cpu_id.c | 4 ++--
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
index 7e2bfb3c3f3b..43f16c052de4 100644
--- a/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
+++ b/tools/testing/selftests/kvm/x86/max_vcpuid_cap_test.c
@@ -30,22 +30,25 @@ int main(int argc, char *argv[])
if (kvm_has_cap(KVM_CAP_SET_BOOT_CPU_ID)) {
vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)MAX_VCPU_ID);
- /* Try setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID */
- ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID - 1);
+ /* Try setting KVM_CAP_MAX_VCPU_ID below or equal to BOOT_CPU_ID */
+ ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID);
TEST_ASSERT(ret < 0,
- "Setting KVM_CAP_MAX_VCPU_ID below BOOT_CPU_ID should fail");
+ "Setting KVM_CAP_MAX_VCPU_ID <= BOOT_CPU_ID should fail");
}
- /* Set KVM_CAP_MAX_VCPU_ID */
- vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID);
+ /*
+ * Set KVM_CAP_MAX_VCPU_ID. Note: KVM_CAP_MAX_VCPU_ID is a misnomer,
+ * it actually represents maximum vcpu_id plus one.
+ */
+ vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID + 1);
/* Try to set KVM_CAP_MAX_VCPU_ID again */
- ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID + 1);
+ ret = __vm_enable_cap(vm, KVM_CAP_MAX_VCPU_ID, MAX_VCPU_ID + 2);
TEST_ASSERT(ret < 0,
"Setting KVM_CAP_MAX_VCPU_ID multiple times should fail");
/* Create vCPU with id beyond KVM_CAP_MAX_VCPU_ID cap */
- ret = __vm_ioctl(vm, KVM_CREATE_VCPU, (void *)MAX_VCPU_ID);
+ ret = __vm_ioctl(vm, KVM_CREATE_VCPU, (void *)(MAX_VCPU_ID + 1));
TEST_ASSERT(ret < 0, "Creating vCPU with ID > MAX_VCPU_ID should fail");
/* Create vCPU with bits 63:32 != 0, but an otherwise valid id */
diff --git a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
index 8e3898646c69..1c4ebdf8e82c 100644
--- a/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
+++ b/tools/testing/selftests/kvm/x86/set_boot_cpu_id.c
@@ -39,8 +39,8 @@ static void test_set_invalid_bsp(struct kvm_vm *vm)
int r;
if (max_vcpu_id) {
- r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)(max_vcpu_id + 1));
- TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID > MAX should fail");
+ r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)max_vcpu_id);
+ TEST_ASSERT(r == -1 && errno == EINVAL, "BSP with ID >= MAX should fail");
}
r = __vm_ioctl(vm, KVM_SET_BOOT_CPU_ID, (void *)(1L << 32));
--
2.55.0.508.g3f0d502094-goog
next prev parent reply other threads:[~2026-07-30 18:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 18:24 [PATCH 0/3] KVM: x86: Fix off-by-one in max_vcpu_ids bounds checks Dmytro Maluka
2026-07-30 18:24 ` Dmytro Maluka [this message]
2026-07-30 18:24 ` [PATCH 2/3] " Dmytro Maluka
2026-07-30 18:24 ` [PATCH 3/3] Documentation: KVM: Clarify that KVM_CAP_MAX_VCPU_ID is exclusive Dmytro Maluka
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=20260730182425.1223530-2-dmaluka@chromium.org \
--to=dmaluka@chromium.org \
--cc=aashish@aashishsharma.net \
--cc=chuanxiao.dong@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jaszczyk@chromium.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=minipli@grsecurity.net \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vineeth@bitbyteword.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox