From: Yosry Ahmed <yosry@kernel.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Yosry Ahmed <yosry@kernel.org>
Subject: [PATCH v1 02/28] KVM: SVM: Document number of ASIDs CPUID setting
Date: Tue, 28 Jul 2026 00:35:31 +0000 [thread overview]
Message-ID: <20260728003557.1136583-3-yosry@kernel.org> (raw)
In-Reply-To: <20260728003557.1136583-1-yosry@kernel.org>
KVM arbitrarly advertises 8 ASIDs in KVM_GET_SUPPORTED_CPUID for
historical reasons. Advertising a small number of ASIDs to L1 is
currently harmless, as KVM (L0) uses the same ASID for both L1 and L2,
and flushes that ASID on nested transitions.
However, following changes will add proper ASID emulation and a separate
ASID for L2, minimizing the TLB flushes on nested transitions. At that
point, a full TLB flush from a KVM guest (L1) would flush both L1 and L2
ASIDs, so should be avoided as much as possible by advertising more
ASIDs to L1.
Increasing the value advertised by KVM is tricky, because a VMM copying
the number of ASIDs from KVM_GET_SUPPORTED_CPUID may perceive a new VM
with a higher number of ASIDs as incompatible with older KVM (which is
not true).
Avoid changing the value advertised by KVM, but document that it is
essentially meaningless and does not represent a limit or a hint. Also,
more-or-less encourage userspace to advertise a higher value to avoid
potential unnecessary TLB flushes from an L1 hypervisor.
Suggested-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
---
Documentation/virt/kvm/api.rst | 20 ++++++++++++++++++++
arch/x86/kvm/cpuid.c | 4 ++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a5f9ee92f43e8..2d24bf708d77e 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -9542,6 +9542,26 @@ the APIC ID is found in EDX for all subleaves of 0x0b and 0x1f, and in EAX
for 0x8000001e; the latter also encodes the core id and node id in bits
7:0 of EBX and ECX respectively.
+Number of ASIDs (nested SVM)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CPUID[0x8000000A]:EBX reports the number of ASIDs supported by the processor
+on AMD CPUs. KVM's ``KVM_GET_SUPPORTED_CPUID`` hardcodes this value to 8 for
+historical reasons. This is value is arbitrary and does not represent a
+limit on the supported number of ASIDs, or even a reasonable default value.
+
+KVM allows userspace to set any value (up to 0xFFFFFFFF), and emulates those
+ASIDs by multiplexing them onto hardware ASIDs. AMD CPUs have only ever
+supported 3 values: 0x40, 0x8000, and 0x1000 -- with modern CPUs advertising
+0x8000.
+
+Advertising a small number of ASIDs could lead an L1 hypervisor to perform
+unnecessary TLB flushes (e.g. older KVM would flush the entire TLB when running
+out of ASIDs). Userspace should probably set the number of ASIDs to a
+reasonably high power of 2 value to remain consistent with hardware and avoid
+any misbehavior by L1 hypervisors, ideally one of the values advertised by
+actual hardware.
+
Obsolete ioctls and capabilities
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 9e9cf6538a96e..8187a58fe6736 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1839,8 +1839,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
break;
}
entry->eax = 1; /* SVM revision 1 */
- entry->ebx = 8; /* Lets support 8 ASIDs in case we add proper
- ASID emulation to nested SVM */
+ entry->ebx = 8; /* Arbitrary value for historical reasons. KVM
+ practically allows and ignores all values. */
entry->ecx = 0; /* Reserved */
cpuid_entry_override(entry, CPUID_8000_000A_EDX);
break;
--
2.55.0.229.g6434b31f56-goog
next prev parent reply other threads:[~2026-07-28 0:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 0:35 [PATCH v1 00/28] KVM: nSVM: Optimize nSVM TLB flushes Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 01/28] KVM: nSVM: Flush the TLB after forcefully leaving nested Yosry Ahmed
2026-07-28 0:35 ` Yosry Ahmed [this message]
2026-07-28 0:35 ` [PATCH v1 03/28] KVM: VMX: Generalize VPID allocation to be vendor-neutral Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 04/28] KVM: x86/mmu: Support specifying reserved TLB tags Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 05/28] KVM: SVM: Add helpers to set/clear ASID flush in VMCB Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 06/28] KVM: SVM: Fallback to flush everything if FLUSHBYASID is not available Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 07/28] KVM: SVM: Duplicate pre-run ASID check for SEV and non-SEV guests Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 08/28] KVM: SEV: Do ASID initialization at VMCB initialization Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 09/28] KVM: SEV: Expose sev_get_asid() outside of sev.c Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 10/28] KVM: SVM: Use a static ASID per vCPU Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 11/28] KVM: SVM: Only flush the fallback ASID when used by a different vCPU Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 12/28] KVM: nSVM: Add a placeholder ASID for L2 Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 13/28] KVM: x86: hyper-v: Rename kvm_hv_vcpu_purge_flush_tlb() Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 14/28] KVM: x86: hyper-v: Allow puring all TLB flush FIFOs Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 15/28] KVM: nSVM: Drop svm->nested.initialized Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 16/28] KVM: nSVM: Flush both L1 and L2 ASIDs on KVM_REQ_TLB_FLUSH Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 17/28] KVM: nSVM: Always switch VMCB before leaving guest mode Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 18/28] KVM: nSVM: Split nested_svm_transition_tlb_flush() into entry/exit fns Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 19/28] KVM: nSVM: Service local TLB flushes before nested transitions Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 20/28] KVM: nSVM: Handle nested TLB flush requests through TLB_CONTROL Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 21/28] KVM: nSVM: Flush the TLB if L1 changes L2's ASID in vmcb12 Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 22/28] KVM: nSVM: Do not reset TLB_CONTROL in vmcb02 on nested VM-Enter Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 23/28] KVM: x86/mmu: Rename __kvm_mmu_invalidate_addr() to kvm_mmu_sync_addr() Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 24/28] KVM: x86/mmu: Refactor kvm_mmu_invlpg() to allow skipping the GVA flush Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 25/28] KVM: nSVM: Flush L2's ASID when emulating INVLPGA Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 26/28] KVM: nSVM: Flush the ASID on nested transitions if shared by L1 and L2 Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 27/28] KVM: nSVM: Use different ASIDs for " Yosry Ahmed
2026-07-28 0:35 ` [PATCH v1 28/28] KVM: selftests: Add a test for nested TLB flushes Yosry Ahmed
2026-07-28 1:05 ` [PATCH v1 00/28] KVM: nSVM: Optimize nSVM " Yosry Ahmed
2026-07-28 1:18 ` Sean Christopherson
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=20260728003557.1136583-3-yosry@kernel.org \
--to=yosry@kernel.org \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
/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