From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00E20370D7D for ; Fri, 12 Jun 2026 14:36:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781274973; cv=none; b=qle3u45aMYLN2iNbPOjtDhgZa14jx5jWQiRVXQop0gfNP/M0MCR6AaDxEky2inoDV1sOLUNoFzsMhxd+XVvXxBkCK4wRbIIRG9m4ezLQLEbm5M7YOE7OGVloX2mLW6fEsvLckRk1Ma53r+QVrVKpPxLnNg7rqXRrxByAe6rIUDk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781274973; c=relaxed/simple; bh=aPsklNPo0W8DL5HXCBB++z7kDGPN6SVBg/uNwc4jm0s=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=t4U60y3RzI2pmdVSNSg5nVvN7+QZ1zjABWugOFQRT37qJ7AYo+odeiw3gl5YVSCtbfjCWNdMduknrc15xL17zNV3h80rgjSxQOZ2f0mHSVSrAauQhXw1wkjq6AzRoAf6ltLW1yAgUU3tzJG4V4c0GQOoKv6YJNTVSzM1jGmhyRM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BPEC0BdG; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BPEC0BdG" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-8423efd76c8so828723b3a.0 for ; Fri, 12 Jun 2026 07:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781274971; x=1781879771; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=VTVHpWDAc44gU8kS/zE/FGdewgWSDCACvR7pfF1CeHQ=; b=BPEC0BdGTktGoRQv6bWhr4p79IrM8xexGVsZhIcVwEe6tiwJ0NpcdRynoIym+rTMMU oqwyc+tOLSCfT65iSXHwf6uG9D7ac+z08tLxd16dBPlQt3OcpERfiblS1WCOOc3/WoKe Qn28mA/JaNLv3m5HBqogjGn/ELkNm+vqXyRaEYNE3r3kF2cHKMohlbXE1Rpxz72OvF1H xvELDLzFaz/qz/dyT4sZB8JuzqSThAcw+g3HnNV5nu+7bKxwGBl7Lo42C4bZBcsjLbgu 0ggsscNDncd6YuUHi86tj3llI8KhSvRvlEl8bsUJ/AsskzNAjXHqVIhwaO7186ZTalY+ L8Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781274971; x=1781879771; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VTVHpWDAc44gU8kS/zE/FGdewgWSDCACvR7pfF1CeHQ=; b=NlMxRDku+pKobYJniFPeQauzGLe5VY9FDBebOzS5RF7pcNojfIoSmY2sqxf9ZBKb9r lxqCXGfjaw4TYdrE7Vikj0z2XOo92pSoZ/3FXEFlz8QdQbPa3iGjx46SZTBWDemjDKvG 0YNQbkm/G3xGbcCGc5wFeTwNkNUy3YLsWyBbx6ic7BFyirfH9TEpqVoNLTavlY5THy4f pN5NBRo5L+QG62cBznUqBYfaRnlsz32dK163El97wpMMRQpFAjkbBz4fGRnPMAcuF2Um UoCNMMDD+4A9jYBlg1enBce30c6likDOZEIKk7riH1T8i0lu1+70nt+VQfRzCxxjvlkj uNEg== X-Forwarded-Encrypted: i=1; AFNElJ97iSS/9z2nnaKXI1XscTQcriEeUwxCKYBrx6fR8VPBEwCAsTO+CsqC7TS5kaUh9okef51IOaVw/qFBB6w=@vger.kernel.org X-Gm-Message-State: AOJu0YxscLRWcpy790QzStRmUY34bEGmYgBNqJm2kS82W+U/pUjbK3l0 l5KHva5bkpy6Gg4IkElyozXgtUcNCX3QtSdKg4wai1AJxHkj+snfjpa3dP7G4zEp X-Gm-Gg: Acq92OFJc7I2EUFmhhb4RwV3CyQ1FkHDPgV9jnqvBXNGOLcGfdSSH7jvc9AL7tpWJ9z drhYbHnyz0xcOOgfI1kCuG5wr7Hj2OyIIrAgfXOABMnfZaXF7B9IV/xU6RvGTzt1jQXRpvitX4J S2Nmyw9b/3G9iPDiTY+20WlVA/AkOHSimzGrhbGeJV2CNpG4y59osVFjRqV53/QmME0t0TkvE9N tRQt0c+ySr0fe6OBa37l6GZCuu0iQ37OEQYiy1gaXMPGvaPEbiTdZJyDTwKIXrJgttUAhGrotCG w51TYslmZgSl+6K4mkwALF7D2HHEYXknKhdqWIcgLYy9vyxhy2UOeVX1eArD2XkTuesj48gH6El HJXdLRPygh7XGQs9OdtihyXZcxF7Vzq8Y0vERXE1yEdAVgbbYO7ERaDwhR6wKLbCd9L6EVT3CLk jJmVSfWseoLAagnSTYwP0pLR3Xri/TEb68fcSO X-Received: by 2002:a05:6a00:f93:b0:842:46a6:e2cf with SMTP id d2e1a72fcca58-8434ce46552mr3664545b3a.21.1781274971241; Fri, 12 Jun 2026 07:36:11 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434acf039fsm2390771b3a.20.2026.06.12.07.36.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2026 07:36:10 -0700 (PDT) From: Ritesh Harjani (IBM) To: Sean Christopherson Cc: kvm@vger.kernel.org, Paolo Bonzini , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Michael Ellerman , Christophe Leroy , Anushree Mathur , Venkat Rao Bagalkote , Harsh Prateek Bora , Ackerley Tng , Christian Borntraeger , Claudio Imbrenda , Nicholas Piggin Subject: Re: [PATCH v3 RESEND 04/10] KVM: PPC: selftests: powerpc enable kvm_create_max_vcpus test In-Reply-To: Date: Fri, 12 Jun 2026 18:19:37 +0530 Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Sean Christopherson writes: > On Wed, Jun 10, 2026, Ritesh Harjani (IBM) wrote: >> From: Nicholas Piggin >> >> powerpc's maximum permitted vCPU ID depends on the VM's SMT mode, and >> the maximum reported by KVM_CAP_MAX_VCPU_ID exceeds a simple non-SMT >> VM's limit. >> >> The powerpc KVM selftest port uses non-SMT VMs, so add a workaround >> to the kvm_create_max_vcpus test case to limit vCPU IDs to >> KVM_CAP_MAX_VCPUS on powerpc. > > How is this not a KVM bug? Literally the reason this test exists is to validate > KVM's advertised KVM_CAP_MAX_VCPU_ID and KVM_CAP_MAX_VCPUS. It's not a KVM bug, it's expected on PowerPC. On PowerPC, vCPU ID encodes SMT topology, e.g. on P9, vcpu id = core * stride + thread, .. where the stride is same as kvm->arch.emul_smt_mode (VM's emulated SMT mode) So the vcpu ID space can be sparse, however KVM_CAP_MAX_VCPU_ID is the absolute ceil value (MAX_SMT_THREADS * KVM_MAX_VCORES) i.e. the value with the maximum stride / SMT value. Since default selftest VM uses stride 1, so it rejects IDS >= max_vcpus. e.g. static int kvmppc_core_vcpu_create_hv(struct kvm_vcpu *vcpu) ... if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) { pr_devel("KVM: VCPU ID too high\n"); core = KVM_MAX_VCORES; /* rejected case */ } else { So, it's expected on PowerPC. vcpus with higher IDs can be created but for that we need to set KVM_CAP_PPC_SMT and use strided (sparse) IDs. But since the test as of now is not doing that - that's the reason why the patch only allows to test max vcpu IDs upto max vcpus. But I guess you must be hating the #ifdef __powerpc__ there. I agree I don't like it either.. maybe we can do it this way? -#ifdef __powerpc64__ /* - * powerpc has a particular format for the vcpu ID that depends on - * the guest SMT mode, and the max ID cap is too large for non-SMT - * modes, where the maximum ID is the same as the maximum vCPUs. + * Some architectures (e.g. powerpc) encode topology into the vCPU ID, + * so a default VM can't necessarily use the full advertised ID range. + * Let the arch limit the highest ID this test will create. */ - kvm_max_vcpu_id = kvm_max_vcpus; -#endif + kvm_max_vcpu_id = kvm_arch_vcpu_id_limit(kvm_max_vcpus, kvm_max_vcpu_id); And then in kvm_util.c - + +__weak int kvm_arch_vcpu_id_limit(int nr_vcpus, int vcpu_id_max) +{ + return vcpu_id_max; +} and lib/powerpc/processor.c can define - + +int kvm_arch_vcpu_id_limit(int nr_vcpus, int vcpu_id_max) +{ + /* + * The stride is the default SMT mode from KVM_CAP_PPC_SMT (1 on + * POWER9+, the host's threads-per-subcore on POWER8) and is always <= + * MAX_SMT_THREADS, so the result never exceeds KVM_CAP_MAX_VCPU_ID. + * + * TODO: exercising the higher (sparse) ID range would require setting + * KVM_CAP_PPC_SMT and creating strided vCPU IDs. + */ + + int stride = kvm_check_cap(KVM_CAP_PPC_SMT); + + return nr_vcpus * (stride > 0 ? stride : 1); +} If this looks good, then I can re-spin a newer version with the following changes: 1. Use above logic in Patch-4 for kvm_create_max_vcpus_test instead of hardcoded #ifdef __powerpc__ logic. 2. Drop patch-5 (print vcpu_id) debug patch 3. Squash all the type specifier changes i.e. Patch 6-10 in the main Patch-3, the patch which adds kvm selftests support for powerpc. -ritesh