Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp49538pxj; Wed, 26 May 2021 15:49:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyNYTZE0c0BIWrlx25M2lfsza9fPHN/fzPdoNmRZijTvqwkDfPFbjJlI9yXM6Xn0/0C4lsD X-Received: by 2002:a05:6e02:13b3:: with SMTP id h19mr523498ilo.142.1622069359190; Wed, 26 May 2021 15:49:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622069359; cv=none; d=google.com; s=arc-20160816; b=zMe0XxWct+SFG5MjMPZVI6njzZ3ur4MXjsw5tBto1H02iQz38FtOCB0qM0mhkg/eby kjngNkQMiagqDb7djpnHDFhL3TArVd0HuCXQ8aV8bf62oRluMClLoj3Ylq+ZdME5p1b3 VWcxZQ+8ZOAil5zgtsCyYnQvhdHeRa3dp7zJD0RwyCblQUo5A0N/AmSVEUUxpdbpsmKQ l+7no/PQdFoVpUkrIyTXli58mM574sunl4ZAnhrylFuN+A8dRSEqHPXgIlHhdWcaF/Ft o9/2C8vYW3FM4TPi6SOX1l/28dN/SHGWXoIka4TohiypMtRRLhrzLq1ELy5FBRoeQwzw nDUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=6bRkgK4UPyvfFe812RqlFX9dKaac3fJKoqFaNKJrN/M=; b=hndA82v0uw2LeV4fsQy4/9kJu+w0pz/2uYGntFR34UWp6xoTEgybTGHueFr3Xh2baT nfDYCTNIK1DB2ijzUGHt0uTHHg1p3E9X+CMadiPHr2ESU1v9/Iwx00rV82gkYgue4FYx PdwMAzqFaU5l8pZQRwiHyQAF3K0s3yETj/EkMupXPGMuFqObSbrFazWsA+2uwkkeuFET ehGcN/Tz/rwodC0/WGnqzhoZ38mLowlUw17ju3v0ZirPA2AUwdJE+cQzzDos0NDFbq4y FzHYObdhrIUiTg3hDdBkME3UiF4H6+E2tbJUglua60xYfHFJJ3fGuUPuxzaGgiVlRspz RFZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dis3AUX1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f17si396374ilc.44.2021.05.26.15.49.01; Wed, 26 May 2021 15:49:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dis3AUX1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234357AbhEZRew (ORCPT + 99 others); Wed, 26 May 2021 13:34:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234009AbhEZRet (ORCPT ); Wed, 26 May 2021 13:34:49 -0400 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3AF7C061574 for ; Wed, 26 May 2021 10:33:17 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id v14so1539318pgi.6 for ; Wed, 26 May 2021 10:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6bRkgK4UPyvfFe812RqlFX9dKaac3fJKoqFaNKJrN/M=; b=dis3AUX1DsE2YtlgCtgvgBvTwtYPf/HiTrK/M1T4RXJxzbONuUu3tZ56zequkYThQo jDlZGfVa+crjvumc9ZkcbVNpcEW82NB61FtqjyVFV1TyHv6xSkRbrtWHaPpSuTFhM2B8 MLqkTkqAS/SUK3JRwKpS+sYaaDKdszpVtn2AbTQNQD1OEDgTnXHx00nmJjPJP5+73qRa APxBRLr9G0ocvdhlCXa26B4bET27dkSjNOBfM2HzS33yPd+okjm4ybGGpfyMC8P8bKbw UI3ZydQlhXgZ2g2kbj/OO/XzNs88s4x0FPsAB16x8955Ry1x6u3h/Aw2OVfXg2FJGe7E C9CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6bRkgK4UPyvfFe812RqlFX9dKaac3fJKoqFaNKJrN/M=; b=j8LFsgoPa8lgAmXrOrl3CYK1PIG0UE0vyzIWmkD0dKjreFzx9yNnwcJmHkhz0wSQNV sY7wUFcvH9P3PaooKZ+wiXwLSuF/7JDKnf9U0YqphO0pIpPVs2BxK05UuAYQFwAz1eUf edf8Qhw0c8ShAO1hxH02PAf8qgAPTUvNKevrifsfW1RpRJVk7wBkVtM58GNJiB51jFGe FIP2RDpdpwcuINviDvv6e1xCn0jvPYNu053C6/utp7S7LfAgQd9oRaH0E9u6A7oETf0h Ojt/Rnr7uZaTmFWrKrgEN3cyvrCMIRuYK3W18yivPDkxCuFRMS60uwoALfnhX3CyaeFb 3n+w== X-Gm-Message-State: AOAM531Mox7T5O9re7MEEizcryuLh5rKSAsCDAy6226O9+nsFSIpoVy1 zV3Ed22Pdax1Bn9E/HRcke2aWA== X-Received: by 2002:a63:1e1a:: with SMTP id e26mr25663798pge.240.1622050397276; Wed, 26 May 2021 10:33:17 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id v27sm7373923pfi.169.2021.05.26.10.33.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 May 2021 10:33:16 -0700 (PDT) Date: Wed, 26 May 2021 17:33:13 +0000 From: Sean Christopherson To: "Maciej S. Szmigiero" Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Igor Mammedov , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Huacai Chen , Aleksandar Markovic , Paul Mackerras , Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 7/8] KVM: Optimize gfn lookup in kvm_zap_gfn_range() Message-ID: References: <38333ef36e7812e1b9f9d24e726ca632997a8ef1.1621191552.git.maciej.szmigiero@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38333ef36e7812e1b9f9d24e726ca632997a8ef1.1621191552.git.maciej.szmigiero@oracle.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 16, 2021, Maciej S. Szmigiero wrote: > From: "Maciej S. Szmigiero" > > Introduce a memslots gfn upper bound operation and use it to optimize > kvm_zap_gfn_range(). > This way this handler can do a quick lookup for intersecting gfns and won't > have to do a linear scan of the whole memslot set. > > Signed-off-by: Maciej S. Szmigiero > --- > arch/x86/kvm/mmu/mmu.c | 41 ++++++++++++++++++++++++++++++++++++++-- > include/linux/kvm_host.h | 22 +++++++++++++++++++++ > 2 files changed, 61 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 7222b552d139..f23398cf0316 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -5490,14 +5490,51 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) > int i; > bool flush = false; > > + if (gfn_end == gfn_start || WARN_ON(gfn_end < gfn_start)) > + return; > + > write_lock(&kvm->mmu_lock); > for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) { > - int ctr; > + int idxactive; > + struct rb_node *node; > > slots = __kvm_memslots(kvm, i); > - kvm_for_each_memslot(memslot, ctr, slots) { > + idxactive = kvm_memslots_idx(slots); > + > + /* > + * Find the slot with the lowest gfn that can possibly intersect with > + * the range, so we'll ideally have slot start <= range start > + */ > + node = kvm_memslots_gfn_upper_bound(slots, gfn_start); > + if (node) { > + struct rb_node *pnode; > + > + /* > + * A NULL previous node means that the very first slot > + * already has a higher start gfn. > + * In this case slot start > range start. > + */ > + pnode = rb_prev(node); > + if (pnode) > + node = pnode; > + } else { > + /* a NULL node below means no slots */ > + node = rb_last(&slots->gfn_tree); > + } > + > + for ( ; node; node = rb_next(node)) { > gfn_t start, end; Can this be abstracted into something like: kvm_for_each_memslot_in_gfn_range(...) { } and share that implementation with kvm_check_memslot_overlap() in the next patch? I really don't think arch code should be poking into gfn_tree, and ideally arch code wouldn't even be aware that gfn_tree exists. > + memslot = container_of(node, struct kvm_memory_slot, > + gfn_node[idxactive]); > + > + /* > + * If this slot starts beyond or at the end of the range so does > + * every next one > + */ > + if (memslot->base_gfn >= gfn_start + gfn_end) > + break; > + > start = max(gfn_start, memslot->base_gfn); > end = min(gfn_end, memslot->base_gfn + memslot->npages); > if (start >= end)