From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 CC6CF3E6390 for ; Mon, 4 May 2026 18:36:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777919789; cv=none; b=MyjbNaYeIbVPtX9qMaRGaqYNhjt0kZ1m2zpKOTl5LVmiIlATEKEFPUJZmH+BW8rIGmoAsoJH8YB29RWcAlEN0NYJaxGJjvL2y5Iv3G+gePtN6swqSlsxq8yaoosAMJEWUHwqQnhqDf8j2f1MOdpddu078oFLOC6frZKfdBO/QUE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777919789; c=relaxed/simple; bh=QFPvIy6dlE9hXF3JqALn/T20CEYJqKHPTfb/KyZtBWM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=kU33xgntSgB4TU2GaAwUVstuA+NHShWIjnmPGns0KwxepNqt+XqIkJXGo/6hND2WOcJhhrk60rlLvq8DUJM6IEB82Plbvz6IpYWDxUMs35vdmfXJXQR93RTv9llK6GL/E4kqOxoMoBE/Nuzu8beHE+rrAukqKf6Pk5LSywuNwM4= 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=igQDUJKH; arc=none smtp.client-ip=209.85.216.73 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="igQDUJKH" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-362eaa3aa61so4514561a91.0 for ; Mon, 04 May 2026 11:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777919787; x=1778524587; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=5jX6vrFPTAfudfQoypDuSTlSrBHCno/qbTt7eNIveuo=; b=igQDUJKH+1QmdZh4YcgSUSNrttMqt19334EgaNZGOKzZdnW4LtXxKqo2D9H5mIS3ck 77SZb/tWE8YZYvmcfqDHHAIsv41NDJktavwIHUvpu25uqAM2QXRvw1VU//eoa2InF07Q PFn2Jpsh5aA3U5AEurfWoyfEs0eK2HKNuqaFXAHzQ5nlQA2U+laqlxP1O4tVYfbCq83N vYJxI3ooQuzHaeY5c1NEFHRFF9BDNGPGbGhp70cVAbckkJUFb6ksNwDdr6PgAr0NXyuv TvJY2OM3eFX7EsGkkQ6sf2Ac0jS8aTB2nYilc2vK1jS3VSCoKqD8k50fLj1JA9x8x+zJ Dp3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777919787; x=1778524587; h=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; bh=5jX6vrFPTAfudfQoypDuSTlSrBHCno/qbTt7eNIveuo=; b=e2XTBcYYkcdbLzv8skuZtY8xXCwTxB5+Jka4I7sErmssO4dhK66Hlw4KxxouiefSm6 pgm080jLT9BghrV5CJLUQRsVS8H3kXycxPQOqxivVbFrx4WjT4PiUeh+59fVt2Wnnh8P NpOTO6VOSTmafaJRxUVrF5ddbBz1aI6Q0WWrUz/L7KDY8P9HOc/GnYV5kSG2LQ1FZqOD b0/nkLwbTJwAG5r5rbWGFWgVwPg4pkM8xwRwVnq83UJg6nCleNpKdJWr0LKjTBuz7gi3 +dlpXTgKukozJreldBXsMDMekqCuc37OwV6fXyvqQWk4w3GyR83fZrcjE6Wauwn+8ROy C0wQ== X-Gm-Message-State: AOJu0YzBTLrLI9H8A3UPcp6je6+svoyBcyfG1z8Do3PHIjjg2jWLlcLg dV2bQplnmxszYoxBEzOJqJeu5pLHuHSJdOhjH5DjpB3jhL3S3QDtT5f0ixY4NMg466EvTnI8vJM Mr4PYnw== X-Received: from pgbg7.prod.google.com ([2002:a63:5207:0:b0:c74:42:899a]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:3d08:b0:39b:a997:9e40 with SMTP id adf61e73a8af0-3a7f1c674ebmr10435101637.46.1777919786961; Mon, 04 May 2026 11:36:26 -0700 (PDT) Date: Mon, 4 May 2026 11:36:25 -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: <20260503210917.121840-1-pbonzini@redhat.com> Message-ID: Subject: Re: [PATCH] KVM: x86: use again the flush argument of __link_shadow_page() From: Sean Christopherson To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Mon, May 04, 2026, Sean Christopherson wrote: > x86/mmu > > On Sun, May 03, 2026, Paolo Bonzini wrote: > > Except in the case of parentless nested-TDP pages, mmu_page_zap_pte() > > clears the SPTE but leaves the invalid_list empty. In this case, using > > kvm_flush_remote_tlbs() as kvm_mmu_remote_flush_or_zap() does is overkill. > > Avoid flushing the entirety of the remote TLBs unless the invalid_list > > was populated: instead, use a more efficient gfn-targeting flush (if > > available) and skip it altogether if the caller guarantees that a TLB > > flush is not necessary. > > > > Based-on: <20260503201029.106481-1-pbonzini@redhat.com> > > Signed-off-by: Paolo Bonzini > > --- > > arch/x86/kvm/mmu/mmu.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > index 892246204435..85bec8eeace8 100644 > > --- a/arch/x86/kvm/mmu/mmu.c > > +++ b/arch/x86/kvm/mmu/mmu.c > > @@ -2541,8 +2541,10 @@ static void __link_shadow_page(struct kvm *kvm, > > parent_sp = sptep_to_sp(sptep); > > WARN_ON_ONCE(parent_sp->role.level == PG_LEVEL_4K); > > > > - mmu_page_zap_pte(kvm, parent_sp, sptep, &invalid_list); > > - kvm_mmu_remote_flush_or_zap(kvm, &invalid_list, true); > > + if (mmu_page_zap_pte(kvm, parent_sp, sptep, &invalid_list)) > > + kvm_mmu_commit_zap_page(kvm, &invalid_list); > > + else if (flush) > > + kvm_flush_remote_tlbs_sptep(kvm, sptep); > > Duh, this is obvious in hindsight. > > Reviewed-by: Sean Christopherson An amendment to that: I thought this was just switching back to the more targeted range-based flushed, I didn't realize you applied the version that hardcoded the @flush param to kvm_mmu_remote_flush_or_zap() with "true". If you take this through kvm.git directly, can you add this comment? /* * Note! @flush from the caller doesn't follow KVM's standard * "collect TLB flushes in a variable to batch them" pattern. * In this case, @flush is used to communicate whether or not a * TLB flush is needed *now*, and specifically only impacts the * case where a huge SPTE is replaced with a shadow page SPTE * (KVM always flushes if a shadow page SPTE is zapped). * * When splitting a hugepage and the new shadow page is fully * populated, i.e. every child SPTE is shadow-present and thus * the total mappings are functionally identical, KVM can defer * the TLB flush (until the ioctl completes) as no memory has * been unmapped, and all mappings are still reachable, e.g. so * that future mmu_notifier invalidations are guaranteed to * flush the affected range if relevant mappings are zapped. */ If you're expecting me to grab this, I'll add the comment when applying.