From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C06139EF35 for ; Wed, 29 Jul 2026 22:50:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785365415; cv=none; b=K27O5B5n66MNrcJ/CLuMqRtgoQC8lfVxt1hu1AJuZPnnopHsdJJQD0UH8zycaKyamwEq/b4xOkBGRr35Cb+RbgIX+RSb7kljXn4Py3ZU4g8i6iK9zBlz73pTnv6whmGx49lxxYsNEPVw1Q+YN2qk5L057CVWfUt6JhrAH00wb7E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785365415; c=relaxed/simple; bh=RMkUPqdU/YmdQZQATNbtW5NBA3Vvme4PzsNPipjmf+k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Ded3aSKQclj3OeMYBNxte8l0ZhUIOUdyZ6+FfDJTPVOgzDeS4Po7gbquvJJERJgv+6xhskbV95LiTr+TiqkSH+8OrDDpLqTxz+8+7UdnMKfIknuU3W69XY3awsl2PlcF0jMfv+ubJ5teEZb2rxpbNyJlWTQNwll2xC4UESNiiWw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=d7Xfjed9; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=eC+J+sKe; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="d7Xfjed9"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="eC+J+sKe" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785365413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=+redXxno3yhMsd+5uVnvErOalNBKKTe/Z8HP7r/UEyc=; b=d7Xfjed9vNHd7qNA4MQRLmoach+90D8l2dlgE6ktuM2jc/7cvaC02pMtldbsyg0h73n+6X 0n5feEC9eXuvqHN8DJgj+RwKHkv5haNynmkI8HtZu8WjBPT9txYUumMVQ0ZJrcQ/KPMed4 xAs//TsxDCRGBqEb5lJYr27GxGB3Im8= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-126-rCF7lvyeMIupERJThxtzZw-1; Wed, 29 Jul 2026 18:50:11 -0400 X-MC-Unique: rCF7lvyeMIupERJThxtzZw-1 X-Mimecast-MFC-AGG-ID: rCF7lvyeMIupERJThxtzZw_1785365410 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-47f726186c4so929805f8f.2 for ; Wed, 29 Jul 2026 15:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785365410; x=1785970210; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+redXxno3yhMsd+5uVnvErOalNBKKTe/Z8HP7r/UEyc=; b=eC+J+sKeJBJPdrMfSrUZznnJo2wC69OfLMtfFONf3JjKJ2V2MyGNqeQKeHveh+CBdK 0Uba7OiVIMMDmQgIHDMJOmvIM/n/a0ddWj4rwPEGExwnXei1YUyXIOdGF/vdlgbsI2pk QqPQcLsoA1uASlKvDu8+49UPO7IqeyQj3rb0NfZaVyH12VMYLkWL7WQERN2YNxACrd8m MXq/ME6RhmeGMC6GLtIfAgKy6ekDxyy7VU0EvCSntcRyGW7EMHiOpsQraSWll+BV8Obb bn9Ra69S/oojyc06m0wlU8JWrjdpyMmwt9WzQ9BkAiGgYALaxl9xTUJ6XczR5fgjubXO zYaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785365410; x=1785970210; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=+redXxno3yhMsd+5uVnvErOalNBKKTe/Z8HP7r/UEyc=; b=gH3dQS+rqWFi9wBw3hG8la9TDNU2zOVVBNKQGhja3Va9Zs8JizFKuwz4+P6LM2m9h4 QCT/tqthln/+infkxiNhZmrwvfaFHDNdlYpIxP+Ck8+1BIfdjCWckM9kTaOofJohBl60 aaKbRAYO19v463our7I2125yW13ImIH6H9oDKmskUB5ZL/477gUnCWYV9HxSc9Am8MqV ClPBOeDxq5EbxUhKlU3w+Tl3lZuvNHLHb7KH1+KOEjwJRzFH5qaxvzo55JJ+5ynpHSx1 JWssL/WpgxqTxC7Zh16rapyQy9QVZHoMZgKNAVWwHoUSqO2qoIvEnCtB8tXFV4Y/XPEX ozwA== X-Gm-Message-State: AOJu0YwlJYNT7huKML26QYK5e55jJLztY/6BFVRgxo41RFQ8WiuzUCSv EEiZUL/Jtd5VyAmkJq58GwjUlhdUgNEwpxH0LxeQUNYy4ehjoR2+zb2Fh7ONJWArVTBQuNIam3E tL7wMWFT2bh8z48VNQr3u6TgGn0hSPpEDjvKDhl7kRd/wQT+rVrquGOMrFpeJ3KDMz74z2oOC2j 4C+NVgG6z+izGIhi3Wy81bMPuV6uYY71aahd5Q4Iu3TSBhA6WdZA== X-Gm-Gg: AR+sD11NcD544sNCHYMLLMX5hFjG5chcJoly/QaXfe23P28dNeb408YhfneNsYajUtz Pw1kuBI1h/KAEYXLT1Ub8mFPz1o/TN+pfq87IMG1NCLBWU6Xy5vMoEJLbee0pIHawT+U6464Kg7 lUUgapXqm/y+qz4/+WZvhR+XBueDmxD+7bQQ81P9+lDrHUV5fVaN5Ap38TSQVVF8UGLs3JVUdSI Y7yZ0EoG3r5qrbSG2cZ5fx3fJZMpZaQyKBYFJa0xG+VA4jWKZf4wpTLwONz/FO7Kkp2PLHosWwq uZ3ClXJfqwqAyhywgKZftdJRHsz5xRKsOFQesTlwOrge1Kvx2e4TBab8xSf4Z2O5hZBVsOTkTmo 3gkbZUag6VIRCf7rzG7eJYiG4ii1TzakihJJQi1W6LzIA1Mo8vllv+Qir0d8EhLPGbdCW4GJs5X M4wxo= X-Received: by 2002:a05:6000:60c:b0:47f:c206:7c4 with SMTP id ffacd0b85a97d-47fc832c6c4mr185233f8f.47.1785365410294; Wed, 29 Jul 2026 15:50:10 -0700 (PDT) X-Received: by 2002:a05:6000:60c:b0:47f:c206:7c4 with SMTP id ffacd0b85a97d-47fc832c6c4mr185207f8f.47.1785365409800; Wed, 29 Jul 2026 15:50:09 -0700 (PDT) Received: from [192.168.10.48] ([151.95.34.92]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fc88e424fsm168020f8f.14.2026.07.29.15.50.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 15:50:09 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Nikunj A Dadhania , stable@vger.kernel.org, Chandrakanth Silveru , Srikanth Aithal , K Prateek Nayak , Tom Lendacky Subject: [PATCH stable] KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug Date: Thu, 30 Jul 2026 00:50:05 +0200 Message-ID: <20260729225006.671397-1-pbonzini@redhat.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Nikunj A Dadhania [ Upstream commit 25f744ffa0c8e799e06250ce2e618367b166b0d4 ] If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle. Fixes: 774c47f1d78e ("[PATCH] KVM: cpu hotplug support") Reported-by: Chandrakanth Silveru Tested-by: Srikanth Aithal Reviewed-by: K Prateek Nayak Reviewed-by: Tom Lendacky Signed-off-by: Nikunj A Dadhania Message-ID: <20260715063506.672432-1-nikunj@amd.com> Signed-off-by: Paolo Bonzini --- arch/x86/kvm/svm/svm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 4d2bacd00ec4..d0971685034b 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -571,7 +571,12 @@ static int svm_enable_virtualization_cpu(void) return r; sd = per_cpu_ptr(&svm_data, me); - sd->asid_generation = 1; + /* + * Bump the current asid_generation value to ensure any vCPU that + * previously ran on this CPU sees a stale generation and is forced + * to acquire a new ASID, preventing a latent ASID collision. + */ + sd->asid_generation++; sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1; sd->next_asid = sd->max_asid + 1; sd->min_asid = max_sev_asid + 1; -- 2.55.0