From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.210.197 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793035994; b=p5Z9+Jy858AHKDWPNo0xPmKvZJmStv82VnVdtQsDpscEen7BabiVgpJu5T8IyH1WYp+l O4jAlLzpaZTykJy0AtxUaze6X8RzHX42BFsEkRu0J+zSqK9opoO+uYyU0A4qPR+EK4bJx wwC0Gc1Vq23Dm+2ISj8x9khev1CdpkAp0EI2rkMIQBY2FOnluQtRLfzABRfLOnO9MzbUu Tll/pu+uc/vunnj3236zY24hTfPb+2DCgCA7XGPooQtTSULZjS1vDz7o5Ygd+mHf+THQZ HezVh2OLvJsf/4Zhoq6ZlKJRSb+RATGnyluQlVxD3vpLtOQaDzsL0nsJHk76cYkcbTA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793035994; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Received:Date:In-Reply-To: Mime-Version:References:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; bh=+/ZMm9aYjbUSd2YiTQuZAI9AV6w5Y2nBgKyqoyIHLWw=; b=qO8R9tjgUj3v22TBLr9EZhAG2+xulKlFd2nfkb7KcD3EM7rKP/QP7fU3Rq5x6BW6NOHh NMr29Z93NVmxWufljwCGk2x/Pougzf5CdHvt9U6QelF0x9Cgq+DZ3XhW69c+/L1ETIB8x j5nHYAl2ZO3bzCF1areVl77cIBfI1SU3C1zJfy6CN016bvOAZhmGBMUL44Cv4LSTMWcwc HC5i/16eFjFx/dlk5D2est9IEnoR9cB6U8a0gaVP6JNEcTWAsndKpke23A8yyw+OgJsIm sEalP4WiQ6nqzLWssEGbEdwnTdtcVkVtjLxO5A7+48SjDsOhYV49MDlA8Dk7WqT/Bwg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20251104 header.b=i2YUP51p; arc=none smtp.remote-ip=209.85.210.197 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2537B606A322 for ; Mon, 26 Oct 2026 17:33:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 2537B606A322 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20251104 header.b=i2YUP51p Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-8a064f294cbso2611618b3a.2 for ; Mon, 26 Oct 2026 10:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1793035993; x=1793640793; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=+/ZMm9aYjbUSd2YiTQuZAI9AV6w5Y2nBgKyqoyIHLWw=; b=i2YUP51phoHzvaj/SMz/PnuMcU370Qehx32+bv+4/p3RvLQAgL8y6y/AfUdoc5V/Lt 5RdjTvnk6dkmPHicypSA0TNhzw8N1Clmi+rlzIvdV/vU5lM7y3kSZrguKyqVWxv5Wlrz sZRefvB+OuseyNlhDY5bk4Rcb8tKy/XespEpABkVkOjrC9cV1feXbBmLmT3TFuFmInZY 8LByrgpevpJwElkHp0oB19GXGfTDG6MAnhRHkfLIrS9KvNgUJj34RpqxDliHJ82TLPul NtXtBmNj7iOoxLJh+liFsYW4izSrfBKwo8iXJc0AR0ES4Hz4TaIqGlPkER9QPIvHVXUx 5Pjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793035993; x=1793640793; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+/ZMm9aYjbUSd2YiTQuZAI9AV6w5Y2nBgKyqoyIHLWw=; b=bTQsZw/8chJs6SeRn3Or0ISJnoiDTCRuJhbm1IaekLfWWQqQ4Cxy7CQzJH8LJmH4X9 aghwo1Tp5NNCtIK6h36DLe6FdZF04YIQ8dp5t0uKpxlm+mqCbuNHdBMep/6Yzjg1RB/6 9hInjfRav0CeduWWU5B2vK3QDpifSNJJb8BbYwJ7LFtxo2TaCiH8buDkMTUbWf6xPF+W 2lyrS7qARiuMnuSh1qzju4e8iaGHur+7+B5pVpJJHrkvJxRagJdrw3mn9NEaHkfJP00+ cTxWVjY30yxOogL+BS3BP+euV0XzAxrHEBfooH1EzKIXF2bzDQRWiK/Z89Uq60P9D64d Nd+A== X-Forwarded-Encrypted: i=1; AKwUvBz8dVNTOS237a6ERp5dvrDn/sS0ppWPsub+DcLhvifBXYXXRdZwVR2nx+vW6DRODmyl1czCrLqU5/DQb9o=@vger.kernel.org X-Gm-Message-State: AFq9FYLlCsJcOiVpqSMC43hnbDTJhu539w24K2F2BtbKjBjd+8Ml8JSK D4xNSkKvGraCu8ahNN3llrLEUP10eS4Lm62csgP/aNYQRH56GO7rc+LKbdfkkUOp28diAAn3fDi x4iWCiA== X-Received: from pgm4.prod.google.com ([2002:a05:6a02:6084:b0:cd8:c65f:79da]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:d81a:b0:3e2:a07b:f383 with SMTP id adf61e73a8af0-3e7cd5a6198mr5636818637.70.1793035993143; Mon, 26 Oct 2026 10:33:13 -0700 (PDT) Date: Mon, 26 Oct 2026 10:33:12 -0700 In-Reply-To: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 References: <20261012233638.2546339-1-yosry@kernel.org> <20261012233638.2546339-27-yosry@kernel.org> Message-ID: Subject: Re: [PATCH v3 26/27] KVM: nSVM: Use different ASIDs for L1 and L2 From: Sean Christopherson To: Yosry Ahmed Cc: Jim Mattson , Paolo Bonzini , Maxim Levitsky , Vitaly Kuznetsov , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Woodhouse Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 19, 2026, Yosry Ahmed wrote: > On Mon, Oct 19, 2026 at 11:50=E2=80=AFAM Jim Mattson wrote: > > > > On Fri, Oct 16, 2026 at 5:25=E2=80=AFPM Yosry Ahmed = wrote: > > > > > > On Fri, Oct 16, 2026 at 02:17:30PM -0700, Jim Mattson wrote: > > > > On Mon, Oct 12, 2026 at 4:37=E2=80=AFPM Yosry Ahmed wrote: > > > > > > > [ ... ] > > > > Per the APM, volume 2, Section 15.16.1, "TLB Flush": > > > > > > > > > All TLB entries belonging to all ASIDs are flushed by SMI, RSM, M= TRR modifications, IORR modifications, and access to other system MSRs that= affect address translation. > > > > > > > > With two separate ASIDs and the unconditional flush removed, do we > > > > flush both ASIDs in the above instances? > > > > > > SMI and RSM, yeah I think so. kvm_smm_changed() -> > > > kvm_mmu_reset_context() deletes all roots, and kvm_mmu_load() will fl= ush s/deletes/unloads, because the roots themselves are almost always still rea= chable through the hashed list of shadow pages. > > > the current ASID when a new root is loaded. > > > > Okay. Is this mechanism obvious to those who are versed in the ways of > > the KVM MMU? >=20 > I don't consider myself versed in the ways of the KVM MMU, it took me > a few minutes to track this done, so I think it's okay. No, it's not ok, though it's also not something that needs to be addressed = in this series. Historically, KVM relied on kvm_mmu_reset_context() to perfor= m TLB flushes basically everywhere, e.g. on CR0 and CR4 writes. It was a nightma= re on multiple fronts, e.g. it was suboptimal when toggling bits that needed a= TLB flush but not a full MMU rebuild, and understanding whether KVM was deliber= ately doing TLB flushes or not was difficult, which in turn made trying to optimi= ze any of that code very painful because it meant disentangling years of KVM c= ode *and* pouring over the SDM and APM to make sure we got the TLB flushes righ= t. In short, the fact that kvm_mmu_reset_context() happens to guarantee a TLB = flush of the new/current root is a side effect and an implementation detail. If = a TLB flush (for the guest) is architecturally required, then KVM should emulate = that exact requirement, even if it means queueing up what will be redundant flus= hes. That makes it easier for newcomers to follow the code, and gives us more fr= eedom to tweak and optimize MMU context changes/resets. Concretely: Author: Paolo Bonzini AuthorDate: Mon Feb 14 11:50:36 2022 -0500 Commit: Paolo Bonzini CommitDate: Tue Mar 1 08:50:42 2022 -0500 KVM: x86: flush TLB separately from MMU reset =20 For both CR0 and CR4, disassociate the TLB flush logic from the MMU role logic. Instead of relying on kvm_mmu_reset_context() being a superset of various TLB flushes (which is not necessarily going to be the case in the future), always call it if the role changes but also set the various TLB flush requests according to what is in the manual. For SVM, the redundant flushes are a complete non-issue. It's basically an= extra memory write. For VMX, the INVVPID isn't free, but for emulated SMM I can't imagine it's = a meaningful performance issue. And FWIW, the only reason not doing KVM_REQ_TLB_FLUSH_GUEST isn't a bug is because hardware isn't allowed to ca= che linear mappings when EPT is in used (and INVEPT invalidates both guest-phys= ical and combined mappings).