From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.216.72 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793921510; b=mGzguhyOOSNmR2OR7YMmCm3UgSZz1jHcuORRaZfKxikI0k1pXZJqNdtsHa9+Rg6QV2XT ekyy/XlhDcSdK7VhMu/+gTCCgH+gYkcYqxGl9OIURIDqUsD0Bi05rWaxrgHJOkUakGDy1 /OaWJGKzm5U3F0T23ucG/sbW/cy8bsvxIdb2mEBsVYuzQl3MQ3gYq0aqWSESImTfJ1HzF qeqz/O9zVFf6YF1zaJoHWvOkRSZj6vpw6Gu8+w0WhkUjkBDCcMUK0sCOlvZH5x4qaer3L H8ZRdgg96zEPfHtfACXU++w15jMNR3tFzYfcI10pXjZA7Svm8eSNpCt/rNE/EaDf6wg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793921510; 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=NaAxVjpBNB4pKTylgaHtCm3wXm5bPQvdxMeR5CSoqlU=; b=k83oGHfhCOkjVNvUgSUCI2sCFvVbmlAFW+SBgJ6ZKt1sCBtu6Vr3JalsfkUCwH6e5RgY UE79MjbmD44S2Tmce7jbpCiZYGBJsxXBKD6HMnwrF5pbSU4xkoR84Mni3eIFqCj/+m4Ew 6v19BzRdo1lZXXc9O0FYWrENQiOgOolEzVVpwhwb4NM4UnkWFozwficza3vjiZGF/jaRQ Pjgof6wNXutqnMHSGPN+Oa7XwQR4fB7kjA6tgy6ehRmZkDd5FKDF52E6CzUOVnhazwdRo GNr2oNFaW1P1Gx19pzjRmNTf0jcglmig1HuqZrG6FZIbDmuKzn2TN2naIt/axMS7O0g== 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=20260707 header.b=X32tjmfW; arc=none smtp.remote-ip=209.85.216.72 Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (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 EE4FE606A326 for ; Thu, 5 Nov 2026 23:31:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org EE4FE606A326 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=20260707 header.b=X32tjmfW Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-3abfcf726dcso124312a91.2 for ; Thu, 05 Nov 2026 15:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1793921508; x=1794526308; 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=NaAxVjpBNB4pKTylgaHtCm3wXm5bPQvdxMeR5CSoqlU=; b=X32tjmfW8Vfe1XC1TL3TN70ZNal1Lhp4TAtbk1rJMMIYYcxSfJfk2hUCuC8bhVMyjd YXIbsBeECAi5pPsC6SIg5QLaC9h22P1famYcbx+qGPnBhLyGF4t+fyYwO1iaF7a1URoT +IVw3GUTc8jXJqDHgEKvgnjh2zjTLGgoTK4iL3+FyivLjF6nvI4c3kzaXtIV8yLZsJH3 pngpWC0CA+ecx667fn6K9/qaw/cCnD0rm49T2WZxxSlRIrX90X1Ut6svhs04nfuJf51p F9yQJ6N0fcvYTaZJWiVPalMKeuzQs6rmmdABnk/rhdtGmtN+Esq2Dp4H/ghj7Zzk4wOa tMXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793921508; x=1794526308; 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=NaAxVjpBNB4pKTylgaHtCm3wXm5bPQvdxMeR5CSoqlU=; b=HZxdo0PHmQ3X52wcGeoOgkqHz03LBq1edPT1nR2avM2zZeRpxaAirp2dYneMCRRMV8 dxUJbz3yiNq54zMvs8/c3mugVgEBchDp+e31C9pOLzFmsY2wx3o55w/mWSqnIjMow0WX qCLq+KtuPFVtLfZEsUTqvE8vEu7hZToPVs2YT7ZWqsdHH7/0eK5y0SBBzvD5L24QemmG HpmEuBz0sO72lCShHZTQmycwWC6j1tUM0hfilWPtBGw+NZGTJoVH88Nh/TR+0lxIXmI5 eyfUYFMRbgbljRk/JmBa5ioYToE5ML2rCbT2x8oEYR4cXpJI5Qp4YKNCrGTyHZkq1CQq IYdg== X-Forwarded-Encrypted: i=1; AKwUvBx8TjJVGAEvaFqVEacBWkWnS+OZyKGHh6FBCJlXI4BlUlaW/21/MTQoc5qonGPChA6q/AhfQIzSsALq+4o=@vger.kernel.org X-Gm-Message-State: APuU4Z8FvdNgRALKTljs5xtkW6JFE4fo8fKPHpvUu8vw2bLvD+i20+fw kSRE9VQdYm10HVl24OO9FXkKu3xsjLZqiRH0BFaZzhurpLyrgBwKuZAB39ezAg8YSMu15qGy1B0 zjsbo+g== X-Received: from pjao9.prod.google.com ([2002:a17:90a:1689:b0:3ab:3d7f:6c0c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3944:b0:3ab:2c2b:1026 with SMTP id 98e67ed59e1d1-3b0db6d1ac9mr578834a91.34.1793921508002; Thu, 05 Nov 2026 15:31:48 -0800 (PST) Date: Thu, 5 Nov 2026 15:31:47 -0800 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 27, 2026, Sean Christopherson wrote: > On Mon, Oct 26, 2026, Yosry Ahmed wrote: > > On Mon, Oct 26, 2026 at 10:33=E2=80=AFAM Sean Christopherson wrote: > > > > > > On Thu, Oct 22, 2026, Yosry Ahmed wrote: > > > > On Thu, Oct 22, 2026 at 3:44=E2=80=AFPM Sean Christopherson wrote: > > > > > > > > > > On Fri, Oct 16, 2026, Jim Mattson wrote: > > > > > > On Mon, Oct 12, 2026 at 4:37=E2=80=AFPM Yosry Ahmed wrote: > > > > > > Moreover, does this change the semantics of PV TLB flush? In > > > > > > record_steal_time(), we have: > > > > > > > > > > > > if (st_preempted & KVM_VCPU_FLUSH_TLB) > > > > > > kvm_vcpu_flush_tlb_guest(vcpu); > > > > > > > > > > > > IIUC, an idle vCPU that wakes into L2 will flush only L2's ASID= . In > > > > > > the past, with a shared ASID, L1's ASID was always flushed on e= mulated > > > > > > VM-exit anyway. Now, L1's ASID will be unaffected. Though I can= 't find > > > > > > any real documentation on PV TLB flush, it *seems* like the rem= ote > > > > > > vCPU would want L1's ASID to be flushed. OTOH, this change make= s nSVM > > > > > > behave just like nVMX. > > > > > > > > > > That's a bug that absolutely needs to be fixed, probably relative= ly urgently. We > > > > > should also document that passing through the steal_time shared i= nformation to L2 > > > > > to utilize PV TLB flushes for L2 is explicitly not supported. > > > > > > > > > > I hate to re-introduce deferred actions for L2 =3D> L1 things, bu= t that seems like > > > > > the only sane way to handle this, because handling the !tdp_enabl= ed case, where > > > > > KVM needs to sync the current root, requires knowing what MMU is = going to be in > > > > > use when L1 regains control. Yuck. > > > > > > > > Are you implying that *you* will be re-introducing deferred actions= ? :P > > > > > > Heh, probably not this calendar year. > >=20 > > Are you opposed to this series landing before that is fixed, keeping > > in mind that it will expose nSVM to the pre-existing bug? >=20 > Nah, though I should just fix the damn bug. It's not hard, I just don't = want to > do it because I don't want to reintroduce a deferred request. Untested, = but I > think this is all that's needed. Early warning, so that you don't post a new version of the series and then = have to respin again. I'm planning on posting a fix that plumbs an @l1_pv_flush= flag around instead of deferring the fix. I realized that KVM synchronizes *all= * MMUs for the !tdp_enabled case, which means that all flushing immediately is ove= rall less risky than deferring the flush (and obviously I was looking for any ex= cuse to not re-introduce deferred actions). I peeked at the rest of this series, and AFAICT it won't throw too big of a= wrench in things. --- KVM: x86: Always target L1 when handling steal-time PV TLB flushes Explicitly target L1 when handling steal-time based PV TLB flushes, as KVM's undocumented ABI for its PV features is that they are scoped to L1, e.g. KVM hypercalls from L2 are routed to L1 or rejected with a #UD. Route a flag through all the flush_tlb_guest() paths to basically ignore is_guest_mode() as appropriate. Note! KVM synchronizes all MMUs, past and present, when servicing a guest TLB flush, i.e. there is no need to switch from targeting L2 to targeting L1 for that specific flow. Alternatively, KVM could defer PV TLB flushes until L1 is active, but the correctness of waiting to synchronize MMUs when TDP is disabled is dubious, as KVM has historically synchronized *all* MMUs for the vCPU. And from the guest's perspective (other vCPUs), KVM has communicated the the flush has already occurred. And in general, KVM has moved away from deferred L2=3D>L= 1 actions, precisely because of similar edge cases. Fixes: 2b4a5a5d5688 ("KVM: nVMX: Flush current VPID (L1 vs. L2) for KVM_REQ= _TLB_FLUSH_GUEST") Cc: stable@vger.kernel.org Reported-by: Jim Mattson Closes: https://lore.kernel.org/all/CALMp9eS8KDozNGT9J_uN69W32QEvTbg2JrtRqN= 0ESi00b_uq=3DA@mail.gmail.com Cc: Yosry Ahmed Signed-off-by: Sean Christopherson diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 0378577d9d8b..51bb66d1618a 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1598,7 +1598,7 @@ struct kvm_x86_ops { * Flush any TLB entries created by the guest. Like tlb_flush_gva(), * does not need to flush GPA->HPA mappings. */ - void (*flush_tlb_guest)(struct kvm_vcpu *vcpu); + void (*flush_tlb_guest)(struct kvm_vcpu *vcpu, bool l1_pv_flush); =20 bool (*vcpu_needs_initialization)(struct kvm_vcpu *vcpu); enum exit_fastpath_completion (*vcpu_run)(struct kvm_vcpu *vcpu, diff --git a/arch/x86/kvm/hyperv.h b/arch/x86/kvm/hyperv.h index 622a6553e9ac..3ece27d34398 100644 --- a/arch/x86/kvm/hyperv.h +++ b/arch/x86/kvm/hyperv.h @@ -312,14 +312,16 @@ static inline struct kvm_vcpu_hv_tlb_flush_fifo *kvm_= hv_get_tlb_flush_fifo(struc return &hv_vcpu->tlb_flush_fifo[i]; } =20 -static inline void kvm_hv_vcpu_purge_flush_tlb(struct kvm_vcpu *vcpu) +static inline void kvm_hv_vcpu_purge_flush_tlb(struct kvm_vcpu *vcpu, + bool l1_pv_flush) { struct kvm_vcpu_hv_tlb_flush_fifo *tlb_flush_fifo; =20 if (!kvm_check_request(KVM_REQ_HV_TLB_FLUSH, vcpu)) return; =20 - tlb_flush_fifo =3D kvm_hv_get_tlb_flush_fifo(vcpu, is_guest_mode(vcpu)); + tlb_flush_fifo =3D kvm_hv_get_tlb_flush_fifo(vcpu, !l1_pv_flush && + is_guest_mode(vcpu)); if (!tlb_flush_fifo) return; =20 @@ -396,7 +398,7 @@ static inline int kvm_hv_hypercall(struct kvm_vcpu *vcp= u) { return HV_STATUS_ACCESS_DENIED; } -static inline void kvm_hv_vcpu_purge_flush_tlb(struct kvm_vcpu *vcpu) {} +static inline void kvm_hv_vcpu_purge_flush_tlb(struct kvm_vcpu *vcpu, bool= l1_pv_flush) {} static inline bool kvm_hv_synic_has_vector(struct kvm_vcpu *vcpu, int vect= or) { return false; diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 581bc3a23c95..f045dc010027 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4304,7 +4304,7 @@ static void svm_enable_nmi_window(struct kvm_vcpu *vc= pu) svm->vmcb->save.rflags |=3D (X86_EFLAGS_TF | X86_EFLAGS_RF); } =20 -static void svm_flush_tlb_asid(struct kvm_vcpu *vcpu) +static void svm_flush_tlb_asid(struct kvm_vcpu *vcpu, bool l1_pv_flush) { struct vcpu_svm *svm =3D to_svm(vcpu); =20 @@ -4313,14 +4313,14 @@ static void svm_flush_tlb_asid(struct kvm_vcpu *vcp= u) * A TLB flush for the current ASID flushes both "host" and "guest" TLB * entries, and thus is a superset of Hyper-V's fine grained flushing. */ - kvm_hv_vcpu_purge_flush_tlb(vcpu); + kvm_hv_vcpu_purge_flush_tlb(vcpu, l1_pv_flush); =20 /* * Flush only the current ASID even if the TLB flush was invoked via - * kvm_flush_remote_tlbs(). Although flushing remote TLBs requires all - * ASIDs to be flushed, KVM uses a single ASID for L1 and L2, and - * unconditionally does a TLB flush on both nested VM-Enter and nested - * VM-Exit (via kvm_mmu_reset_context()). + * kvm_flush_remote_tlbs() or is a PV TLB flush targeting L1. Although + * flushing remote TLBs requires all ASIDs to be flushed, KVM uses a + * single ASID for L1 and L2, and unconditionally does a TLB flush on + * both nested VM-Enter and nested VM-Exit (via kvm_mmu_reset_context()). */ if (cpu_feature_enabled(X86_FEATURE_FLUSHBYASID)) svm->vmcb->control.tlb_ctl =3D TLB_CONTROL_FLUSH_ASID; @@ -4341,7 +4341,7 @@ static void svm_flush_tlb_current(struct kvm_vcpu *vc= pu) if (svm_hv_is_enlightened_tlb_enabled(vcpu) && VALID_PAGE(root_tdp)) hyperv_flush_guest_mapping(root_tdp); =20 - svm_flush_tlb_asid(vcpu); + svm_flush_tlb_asid(vcpu, false); } =20 static void svm_flush_tlb_all(struct kvm_vcpu *vcpu) @@ -4356,14 +4356,14 @@ static void svm_flush_tlb_all(struct kvm_vcpu *vcpu= ) if (WARN_ON_ONCE(svm_hv_is_enlightened_tlb_enabled(vcpu))) hv_flush_remote_tlbs(vcpu->kvm); =20 - svm_flush_tlb_asid(vcpu); + svm_flush_tlb_asid(vcpu, false); } =20 -static void svm_flush_tlb_guest(struct kvm_vcpu *vcpu) +static void svm_flush_tlb_guest(struct kvm_vcpu *vcpu, bool l1_pv_flush) { kvm_register_mark_dirty(vcpu, VCPU_REG_ERAPS); =20 - svm_flush_tlb_asid(vcpu); + svm_flush_tlb_asid(vcpu, l1_pv_flush); } =20 static void svm_flush_tlb_gva(struct kvm_vcpu *vcpu, gva_t gva) @@ -4381,7 +4381,7 @@ static void svm_flush_tlb_gva(struct kvm_vcpu *vcpu, = gva_t gva) return; } =20 - svm_flush_tlb_guest(vcpu); + svm_flush_tlb_guest(vcpu, false); } =20 static inline void sync_cr8_to_lapic(struct kvm_vcpu *vcpu) diff --git a/arch/x86/kvm/vmx/main.c b/arch/x86/kvm/vmx/main.c index d75170a6199e..c2b5c04cd2b8 100644 --- a/arch/x86/kvm/vmx/main.c +++ b/arch/x86/kvm/vmx/main.c @@ -547,12 +547,12 @@ static void vt_flush_tlb_gva(struct kvm_vcpu *vcpu, g= va_t addr) vmx_flush_tlb_gva(vcpu, addr); } =20 -static void vt_flush_tlb_guest(struct kvm_vcpu *vcpu) +static void vt_flush_tlb_guest(struct kvm_vcpu *vcpu, bool l1_pv_flush) { if (is_td_vcpu(vcpu)) return; =20 - vmx_flush_tlb_guest(vcpu); + vmx_flush_tlb_guest(vcpu, l1_pv_flush); } =20 static void vt_inject_nmi(struct kvm_vcpu *vcpu) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index b341af4c6057..e6a61514e797 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -3398,7 +3398,7 @@ void vmx_flush_tlb_gva(struct kvm_vcpu *vcpu, gva_t a= ddr) vpid_sync_vcpu_addr(vmx_get_current_vpid(vcpu), addr); } =20 -void vmx_flush_tlb_guest(struct kvm_vcpu *vcpu) +void vmx_flush_tlb_guest(struct kvm_vcpu *vcpu, bool l1_pv_flush) { /* * vpid_sync_context() is a nop if vpid=3D=3D0, e.g. if enable_vpid=3D=3D= 0 or a @@ -3407,7 +3407,10 @@ void vmx_flush_tlb_guest(struct kvm_vcpu *vcpu) * disabled (VM-Enter with vpid enabled and vpid=3D=3D0 is disallowed), * i.e. no explicit INVVPID is necessary. */ - vpid_sync_context(vmx_get_current_vpid(vcpu)); + if (l1_pv_flush) + vpid_sync_context(to_vmx(vcpu)->vpid); + else + vpid_sync_context(vmx_get_current_vpid(vcpu)); } =20 void vmx_ept_load_pdptrs(struct kvm_vcpu *vcpu) diff --git a/arch/x86/kvm/vmx/x86_ops.h b/arch/x86/kvm/vmx/x86_ops.h index cd72684d075d..67e5dd728267 100644 --- a/arch/x86/kvm/vmx/x86_ops.h +++ b/arch/x86/kvm/vmx/x86_ops.h @@ -82,7 +82,7 @@ bool vmx_get_if_flag(struct kvm_vcpu *vcpu); void vmx_flush_tlb_all(struct kvm_vcpu *vcpu); void vmx_flush_tlb_current(struct kvm_vcpu *vcpu); void vmx_flush_tlb_gva(struct kvm_vcpu *vcpu, gva_t addr); -void vmx_flush_tlb_guest(struct kvm_vcpu *vcpu); +void vmx_flush_tlb_guest(struct kvm_vcpu *vcpu, bool l1_pv_flush); void vmx_set_interrupt_shadow(struct kvm_vcpu *vcpu, int mask); u32 vmx_get_interrupt_shadow(struct kvm_vcpu *vcpu); void vmx_patch_hypercall(struct kvm_vcpu *vcpu, unsigned char *hypercall); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 26e7beaff8a0..3bbd15b64e99 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2009,7 +2009,7 @@ static void kvm_vcpu_flush_tlb_all(struct kvm_vcpu *v= cpu) kvm_clear_request(KVM_REQ_TLB_FLUSH_CURRENT, vcpu); } =20 -static void kvm_vcpu_flush_tlb_guest(struct kvm_vcpu *vcpu) +static void kvm_vcpu_flush_tlb_guest(struct kvm_vcpu *vcpu, bool l1_pv_flu= sh) { ++vcpu->stat.tlb_flush; =20 @@ -2024,13 +2024,13 @@ static void kvm_vcpu_flush_tlb_guest(struct kvm_vcp= u *vcpu) kvm_mmu_sync_prev_roots(vcpu); } =20 - kvm_x86_call(flush_tlb_guest)(vcpu); + kvm_x86_call(flush_tlb_guest)(vcpu, l1_pv_flush); =20 /* * Flushing all "guest" TLB is always a superset of Hyper-V's fine * grained flushing. */ - kvm_hv_vcpu_purge_flush_tlb(vcpu); + kvm_hv_vcpu_purge_flush_tlb(vcpu, l1_pv_flush); } =20 =20 @@ -2052,7 +2052,7 @@ void kvm_service_local_tlb_flush_requests(struct kvm_= vcpu *vcpu) kvm_vcpu_flush_tlb_current(vcpu); =20 if (kvm_check_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu)) - kvm_vcpu_flush_tlb_guest(vcpu); + kvm_vcpu_flush_tlb_guest(vcpu, false); } EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_service_local_tlb_flush_requests); =20 @@ -2118,7 +2118,7 @@ static void record_steal_time(struct kvm_vcpu *vcpu) trace_kvm_pv_tlb_flush(vcpu->vcpu_id, st_preempted & KVM_VCPU_FLUSH_TLB); if (st_preempted & KVM_VCPU_FLUSH_TLB) - kvm_vcpu_flush_tlb_guest(vcpu); + kvm_vcpu_flush_tlb_guest(vcpu, true); =20 if (!user_access_begin(st, sizeof(*st))) goto dirty; @@ -8193,7 +8193,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) #ifdef CONFIG_KVM_HYPERV if (kvm_check_request(KVM_REQ_HV_TLB_FLUSH, vcpu) && kvm_hv_vcpu_flush_tlb(vcpu)) - kvm_vcpu_flush_tlb_guest(vcpu); + kvm_vcpu_flush_tlb_guest(vcpu, false); #endif =20 if (kvm_check_request(KVM_REQ_REPORT_TPR_ACCESS, vcpu)) {