From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) (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 A35953E47B for ; Mon, 27 Jul 2026 15:38:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785166711; cv=none; b=T8R0GxSHRLVyzTdme/LjEKb5hI4qWwpF2nhMv1MOpZWGUuZEEzxnqZDoxc3AI5z0ZkegeyreAzLIbOJ5Iwrc7mOX+TwZdHn3y6H2KsK8ZPePZpP5EvMLTXg9npEoTNXPnGOCLkqs8A1s6y6hqlXHjLTyGQoSdZ9wYS97eq9Uzc0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785166711; c=relaxed/simple; bh=G5Fwl6ud9evOZIYHGQkeNauVJz12mLkmiRAJ68t7i+c=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ZiVYYL7S01KnXdn06n1beyfumyl8qRrOaUet1RNqtHjZzuFOiJ0D1idiojz9dQidD3dlhBoSOf2pApLexZakHJTg3mIjKCjDjgV5agTLbCbwlINQImogWTTOkO2+abIFOlGbVGlto5oBsCmmre+mRe7rymOAPaMc/BCJT1ful+s= 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=ebfynwDj; arc=none smtp.client-ip=209.85.210.200 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="ebfynwDj" Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-84885a4fcabso3318762b3a.3 for ; Mon, 27 Jul 2026 08:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785166708; x=1785771508; 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=gHRhqfLK6c/QdmdMnR944OptUWndEHMP2Gs3FISc6B4=; b=ebfynwDjwLQVJV0lTeUJOh4p1bQr0mtlGy4MsCP8VmSSZ/bV7PkI7AjLae+DG8X6eO /g/lr3E64MnUXo9DiKyQYyZvSRClDcOK+zxcqRVnvgRKK/Xs55xSW0Do+4w4eahbgTYl EAq1jX+S1Buv3GFRxWNiBeLFRsLs/tOKvLiyjCHyiI40bcdjP52bY9Q4h19Z39yKLlhL xXfMt/Mcv5PeZoGhgqhAarD+8uSOe1A/SrgEcZul1a8q9nlAhoxTmrY1mw3H+ytLBR9Z XkcdGoJ/t71araQHJqM5XqzdM2FmYChhp7Dt+/98OkLSXdBIGAoT3vPdhAftVt//CLnj iCZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785166708; x=1785771508; 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=gHRhqfLK6c/QdmdMnR944OptUWndEHMP2Gs3FISc6B4=; b=ggf5AwrPTrlnzUVrqI5MXMBJnhHfHc/pnvysbOllIz6+MBOClMHa1ydpfeGiFrGwxS OZAYWxeChlZTiWQHXDGi0l1gdigEpD9U9F7OK34yfXIj65ZpfCkVxHnybiWNLuX1FrFX 8QbbhgUpdYCWa8UnZeTFv7Uafhv1CmvR9muxyckSAzxFzra4sqLPJnNcgfU89zafqq+1 5v5WmN5JUkaN3m+1loV2yxmNSrgzfg6Aa7ejW8CbjYuPkE0sJ/mAtGEanc5oiur02fZQ O1doJzls/3Y2Ub3IuEhMGzIYONEo4YzhAuyb43cu8kfx62pgE6jixewhwfuUG6hvHm84 5mag== X-Forwarded-Encrypted: i=1; AHgh+Rp4dvk0cDBWLf4aUqU3GgzhOLPVUBEtNNDgUSzVuB2F2IEd3vjt0r4Xb9U9pok9cg9z5rRclldsu54XO6s=@vger.kernel.org X-Gm-Message-State: AOJu0YwxXlzbsnzPHaLxe4wUBbVUBzFqJcQwFVZvFoGALFQhbV3Gbv9w 9V9FPkJTsmvZxshk2IblBmDjDFFgRFjtUO8sSm1t93AUvJ6pdDnzLyZpaNzSRNe3NDDi7sMe197 fz0nlCA== X-Received: from pfwp23.prod.google.com ([2002:a05:6a00:26d7:b0:845:e386:e036]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:94f9:b0:848:6447:e0a6 with SMTP id d2e1a72fcca58-84e5942da59mr6622547b3a.9.1785166707621; Mon, 27 Jul 2026 08:38:27 -0700 (PDT) Date: Mon, 27 Jul 2026 08:38:27 -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 Fri, Jul 24, 2026, Yosry Ahmed wrote: > > > > > > 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. > > > > > > Yes, it's skipping the TLB flush that is only needed for GVAs. The > > > alternative I had in mind (but thought was worse) was to refactor the > > > TLB flush part out of kvm_mmu_invalidate_addr() (or > > > __kvm_mmu_invalidate_addr()) in this patch instead of adding a boolean, > > > but this still requires adding a wrapper and the possibility of a > > > quad-underscore helper. > > > > > > What's the main objection to kvm_mmu_invalidate_addr_in_root()? > > > > I don't love the __kvm_mmu_invalidate_addr() => kvm_mmu_invalidate_addr_in_root() > > callchain. It's not at all obvious that the in_root() helper shouldn't be called > > directly. I don't hate it, but I do think we need better clarity on what all this > > is doing. > > > > E.g. when looking at __kvm_inject_emulated_page_fault(), since it hardcodes a > > single root, it's a bit headscratching to use kvm_mmu_invalidate_addr() instead > > of kvm_mmu_invalidate_addr_in_root. > > Coming back to this, I agree it's confusing. I think this can be fixed > with a better name though. Looking at > kvm_mmu_invalidate_addr_in_root() (or __kvm_mmu_invalidate_addr() in > current code), seems like what it does is find SPTEs for that address, > sync them, and flush the TLB if needed. > > So maybe mmu_sync_addr_sptes() or mmu_sync_and_flush_addr_sptes()? kvm_mmu_sync_addr()? The "sptes" part is implied in things like kvm_sync_page() and mmu_sync_children().