From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (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 9BF482BB13 for ; Thu, 23 Jul 2026 00:53:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784767990; cv=none; b=dUyygF/S1HiKPFL3nFNO30Vq7hy7IDAllrXB0uAPL00YC2nMLkzgmt7cfJoiyySMNAXLaOjWsA7oAz7OhLC7T8QIzuru+FAAeG1UCoEPW4F/UB9u5EeVOU2a3Rg+tI2q8RgGA+nLpPwKutQOCV80nG/n7eKeLxjZFpRdepV9hWQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784767990; c=relaxed/simple; bh=W8zO0aEDv2+JIislquQ6WLUjQVKy+IVFjZc4VH0Dr4g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=RP5w7AiOr2cos90tmIS6MJwfXkyU7fe1zayMTDHWiwdodn/T3TIFxk6cq+tQD0EZZQVTp3MH7NXaXcrBgvBmTBYMW7xBBgi5NEv2j+1mHMMix17tBU/MEz6chLcYgPQJWADBl/lMNkpBluwOracZ/wNQxSqELK3LXoWNy/SkmCo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=IHjHiULA; arc=none smtp.client-ip=209.85.210.199 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) header.d=google.com header.i=@google.com header.b="IHjHiULA" Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-8485b7e18b4so175419b3a.1 for ; Wed, 22 Jul 2026 17:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784767989; x=1785372789; darn=vger.kernel.org; h=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=opFEo/WyLvzTTBdcJgd0dRDPizwBHzhn8Zc4yWr1cd8=; b=IHjHiULARNSQoL/JlUTK/QNEL1eFBS7W/3ZHl9rfszBNkEULgNC0dyuYcI1kfb8brz sqbsHKMjf7lh31+m0PhREJzme/egXigljqt2FLtZY9VaP1OC8kkl9yBXmVvO2wKOdvlF YclAE+FgQu65kbappkISvdnLn7c72sN83CCiwGVfVO8J6up+ClKnBuOkUeyKQbKixHzE aHcNJR5egwMREo2mAANZjFTYoVll+5P7lWxnHyE2EPc/yvA5LzHTg9flyFCXEPJy+vVl CUOKyLcFDKk7jKB0nMy0XIqK5dUD5yHmnu9kkh7v9kVFIiFmI2E9uUhQVwzZK4jTCO46 ABpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784767989; x=1785372789; h=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=opFEo/WyLvzTTBdcJgd0dRDPizwBHzhn8Zc4yWr1cd8=; b=VSZtm8agzCvof9rRjuN5aQznxXhxJMVas9c5iPDMODXNS4MD24VKjQzKee3Z5CGzff g8cYa0qL0Id31i+21BHvo3CHKKZosFSSKDXKg0YiygH+HPczGrlF/vYSZ+6Kgxv4F1yX +Ok6aftFbICcr4Bq0kdZ4jAleEhfkr3aMkSZSSn2TSM9TPjgIsc0Ve8Eed/FPhy8NsRS Ai5akYBx7M8dcuYm8KIEzfeC0nVcOX9TDOdbYrdO0vORo2ATH/AkVMsFnkmgAZxdNrzS SK4OeQLWqCPUGfltm9ailSI8kXZ14Oi27G1XEfVDlRlfQZHjWrXNRR9sN88N1TR/Bfu4 QM7g== X-Forwarded-Encrypted: i=1; AHgh+RpHxblQYODQGqelSg2d3Dg6g/OjKGdT4RN1Gif3XZra4PUgbkNuRVJ2/MS5QWx8dnUBiuhzv5v8TY/1KIk=@vger.kernel.org X-Gm-Message-State: AOJu0YzzvtI6mIoKhRILbtfdhdTAgbOhqRoeF+COxGipXUyvjIdduPtC yOKQPZOEtVYgkYKDRL2yrcKIJAKhX8dFl0t9IblVBZawT3abgY0tusml127rmBdcZ5sVaPWUxC9 Pz6fQcQ== X-Received: from pgbca34.prod.google.com ([2002:a05:6a02:6a2:b0:c88:dea2:d511]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:6ca0:b0:848:4810:2b71 with SMTP id d2e1a72fcca58-84e2bbca960mr1187249b3a.51.1784767988593; Wed, 22 Jul 2026 17:53:08 -0700 (PDT) Date: Wed, 22 Jul 2026 17:53:07 -0700 In-Reply-To: <20260616004155.1435766-23-yosry@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260616004155.1435766-1-yosry@kernel.org> <20260616004155.1435766-23-yosry@kernel.org> Message-ID: Subject: Re: [RFC PATCH v2 22/25] KVM: x86/mmu: Refactor kvm_mmu_invlpg() to allow skipping the gva flush From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , Jim Mattson , Maxim Levitsky , Vitaly Kuznetsov , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Tue, Jun 16, 2026, Yosry Ahmed wrote: > Refactor helpers out of kvm_mmu_invalidate_addr() and kvm_mmu_invlpg() > that take in an extra argument to skip the GVA flush. > > This will be used when invalidating GVAs in a different context than the > correct one (i.e. invalidating an L2 GVA from L1), so flushing the > current context would flush the wrong TLB entries. > > No functional change intended. > > Signed-off-by: Yosry Ahmed > --- > arch/x86/kvm/mmu/mmu.c | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 65c35ed8f4a01..3feb75732f7b4 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -6615,15 +6615,15 @@ static void kvm_mmu_invalidate_addr_in_root(struct kvm_vcpu *vcpu, > write_unlock(&vcpu->kvm->mmu_lock); > } > > -void kvm_mmu_invalidate_addr(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > - u64 addr, unsigned long roots) > +static void __kvm_mmu_invalidate_addr(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > + u64 addr, unsigned long roots, bool flush_gva) > { > int i; > > WARN_ON_ONCE(roots & ~KVM_MMU_ROOTS_ALL); > > /* It's actually a GPA for vcpu->arch.guest_mmu. */ > - if (mmu != &vcpu->arch.guest_mmu) { > + if (flush_gva && mmu != &vcpu->arch.guest_mmu) { > /* INVLPG on a non-canonical address is a NOP according to the SDM. */ > if (is_noncanonical_invlpg_address(addr, vcpu)) > return; > @@ -6642,9 +6642,15 @@ void kvm_mmu_invalidate_addr(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > kvm_mmu_invalidate_addr_in_root(vcpu, mmu, addr, mmu->prev_roots[i].hpa); > } > } > + > +void kvm_mmu_invalidate_addr(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > + u64 addr, unsigned long roots) Rather than kvm_mmu_invalidate_addr() for the wrapper, what if we call this kvm_mmu_invalidate_gva()? And then kvm_mmu_invlpg_gva(). Then we don't need to have the "in_root" version to a quad-underscores helper, and IMO it's more obvious what's different between the one-line wrappers and the inner helpers. > +{ > + __kvm_mmu_invalidate_addr(vcpu, mmu, addr, roots, true); > +} Make these one-liners static inlines to avoid the export, and because they're trivial wrappers that should be inlined. > EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_mmu_invalidate_addr); > > -void kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva) > +static void __kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva, bool flush_gva) > { > /* > * INVLPG is required to invalidate any global mappings for the VA, > @@ -6656,11 +6662,16 @@ void kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva) > * be synced when switching to that new cr3, so nothing needs to be > * done here for them. > */ > - kvm_mmu_invalidate_addr(vcpu, vcpu->arch.walk_mmu, gva, KVM_MMU_ROOTS_ALL); > + __kvm_mmu_invalidate_addr(vcpu, vcpu->arch.walk_mmu, gva, > + KVM_MMU_ROOTS_ALL, flush_gva); > ++vcpu->stat.invlpg; > } > -EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_mmu_invlpg); > > +void kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva) > +{ > + __kvm_mmu_invlpg(vcpu, gva, true); > +} > +EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_mmu_invlpg); > > void kvm_mmu_invpcid_gva(struct kvm_vcpu *vcpu, gva_t gva, unsigned long pcid) > { > -- > 2.54.0.1136.gdb2ca164c4-goog >