From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (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 234A7212F89 for ; Thu, 23 Jul 2026 00:56:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784768182; cv=none; b=q3nCUCmaZYEP6AgnsF/92w/7AYq6+Lq2t0vfT//5jyqzykcDlZJ+iINIBUheJAnpylusA7T+mZEIhj8KiS7HJHykLZYLZE8WDT2T6k8pvK5O0z0NAcDjVZ9eF62No/juI91OkyvnCTwQC/a/fFvlxCRAUDvXzbPTxPAyanc/Mms= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784768182; c=relaxed/simple; bh=LHdVCehwG3HvJYaxZhqKZcT5rZZsELkJdogfR1KfAMY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tZFRZQuAsQXNYARLAyVsuoUdB6wHudg4Q/unZDCGQwTHF6DHdXRDXAgop/6C9Zs8cnoEkDkzZAMJKe5p4A6wIOTiZiE1oMfjXUdVyo7cT3rBLqNzLxAb3+O74IJ0FLprUZPoEDTZpDJ5ExqZuVlxmGTAqmxxwXdKAUeg3dOyDLU= 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=l4Fm7ZY4; arc=none smtp.client-ip=209.85.210.198 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="l4Fm7ZY4" Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-84e024d2129so200416b3a.2 for ; Wed, 22 Jul 2026 17:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784768180; x=1785372980; 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=yBVSNQ6EdYayMHw9yILA6H3pFc9jV95YBn1yRdp33VE=; b=l4Fm7ZY4kCH2/D+4/oWNWMMt5gNuIJ13+OV/zUm0ZNwPJJYm1zf6z72MzUL3O38gje 1io2aX20RPPzP7npUbtvCKBG/HO2q/mNItSNQPJt2qyk6WkbyBTo9USPsAjTqzDYykzJ 6iY6cuqsRmFdSHNtK5EieR3gDMoih1ZhuLTzBctzVilQhlFMMA9AO9dEABHl5L7Z7v+O QslAxUBQemNuzPzPvuYnYYCY0qwbIb2lAc2nZMajrF2sfAyzeS9UlQScYHhMrGcOZHYS sLW3fKiT6HyB/T3itm19SJAhYtJ64rzm1MR/gXglwwHK6MMC19UwWWOeKbzP9Ro8zNJk GK3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784768180; x=1785372980; 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=yBVSNQ6EdYayMHw9yILA6H3pFc9jV95YBn1yRdp33VE=; b=kzQ0mUcOdtczeVL74yW7AunXUNFf5kprWEKY7vye10i/yCkYjnsgtcUbLnsSkGW2Ke 6zgTymjuZoCZY2tEPp7oIH4RrCGmPlvhQog4T4iMZpprJm5fJ7+aigTaM7yi8aL81uDR Min2+XPIa9NT0nPoJpnybTqrDqiygM1fCm1yGoigiY7w0K9Je5q7FdwwjIPFLVlQqDt6 yzgC03Nvr1rrYCSPrFGvXojhgly0Hi05cFy7UvRX6d8a8WK5TO1uLAyP8VLVLnsQibwE DhjF48f1VKlY8vNljUeIg0TymxDrkdRMAmGWNU79oWFwz+BTvs8urBfLkaBku0UJdtwY eD4Q== X-Forwarded-Encrypted: i=1; AHgh+RoKA8L1ngPR5saTI8P7WE8ntocGFmMAZ5WokPxJnEVvxJmjlkJ9I6tUno3akiC8V8YAZsgl2L5FsqTGfeo=@vger.kernel.org X-Gm-Message-State: AOJu0YyHkHy9gglYqqj/5DmBLu7zrtqPmfcNmz9j49j5eQLcRn7rbj6a BchERGctrxRXuWi8A6/0TAKpMNLj//SXeHiAJ4wbT9UJLDj0iKjbvF3LWR+SuCPIviH3jRAF34S YtoBAPA== X-Received: from pfbhj14.prod.google.com ([2002:a05:6a00:870e:b0:845:e683:1287]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:181c:b0:82f:50cd:e586 with SMTP id d2e1a72fcca58-84e2bbeceabmr1218273b3a.13.1784768180132; Wed, 22 Jul 2026 17:56:20 -0700 (PDT) Date: Wed, 22 Jul 2026 17:56:19 -0700 In-Reply-To: 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 Wed, Jul 22, 2026, Sean Christopherson wrote: > 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. Hrm, or maybe I'm not understanding what "flush_gva" means. At first glance, I was assuming you were using it to differentiate between GVA and GPA, but IIUC, it's literally skipping the flush for the current context, which just so happens to be done only for GVAs. I'd still like to avoid the "in_root" helper, if at all possible.