From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FA5FC4332F for ; Fri, 4 Nov 2022 22:29:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2D226B0071; Fri, 4 Nov 2022 18:29:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDD948E0001; Fri, 4 Nov 2022 18:29:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA4C26B0074; Fri, 4 Nov 2022 18:29:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BB6BE6B0071 for ; Fri, 4 Nov 2022 18:29:55 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9035240181 for ; Fri, 4 Nov 2022 22:29:55 +0000 (UTC) X-FDA: 80097203550.25.CB8000A Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf19.hostedemail.com (Postfix) with ESMTP id 437D71A0002 for ; Fri, 4 Nov 2022 22:29:54 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id k7so6137385pll.6 for ; Fri, 04 Nov 2022 15:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5Aq/mVWfLwMWGNt8fSCRAZ8qaQX+Rp9/roFUUSHdFcg=; b=dKOKOca6Gt2YyKKroo64YoypifXCi0Cnu7uvNh/c1CQKTYDigZb1a5Lc6nfrrUEMI/ 4AE2r5sOnFMf/n4N6rkqJkEinjHy10LPkOYq61AodJoYbUhGCTtIzVhqSoARiYYRtFo/ EclovTivzigbK81kGBQRDG0qF26K9JY+bLhX0J0qVedsSALXRnsV1mIYQbLUA7RdI4Bl F8BWIJWldzMyvETppjo+2Y4ZQDwmlrfV9ZT/zySDdpk9yZyTmfAxbwSHbaM4LwBFWmC7 KyZY28moUsv5znWRMH9QPRY8B1+WPpJCb1AVkbrC9wmyWUSfTKUMmauuTdOpubCs51OC 6Y/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5Aq/mVWfLwMWGNt8fSCRAZ8qaQX+Rp9/roFUUSHdFcg=; b=Ko2PaYIbiRCzVPW0k5i+qU2nKLZXlIXqC6p6HqCd5sM+S9h+g6vJt1AQhDak+4qHPM AI+m6kDbVhl/C+x2VQqmu1FIiOhMkBW3BYeiu/7xVNlim/gtNpud84NxXjCZR7B2dIw9 hqWRNsNMcux5GQ4rV7b0PV5XJ3ywwU/63Tmvhq+ByDbD8FRaQlGfN9C3lHEK4fgKzD2H Lvgn3j6srYtijstp05l5iuOW1lizN0er99R64lPNehOm9IeWixeqIwnRaogd+DrfGtFG 38nbUwU+79A+7mekPgxU4ZGM8lW18YzaGoWrPxbN0y0PmkJVZxriaCGAm63WWppKS3Q+ 6wrA== X-Gm-Message-State: ACrzQf3d2rpRob2qK2v3x7PsyVse0UEH5UMzxhoiLHJHedTHHmRAovhN bj2LY82xNBH4JBarJRKZvT1LEg== X-Google-Smtp-Source: AMsMyM6o08bPyM7u13HIMLyxzK/w69wLSfIdjhMYyTpFlvV74UC9l3d3wEgtuR0o04KYkQ2hwL/GmQ== X-Received: by 2002:a17:903:2645:b0:185:480a:85d2 with SMTP id je5-20020a170903264500b00185480a85d2mr37750861plb.144.1667600993126; Fri, 04 Nov 2022 15:29:53 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id s11-20020a170902ea0b00b0018700ba9090sm237049plg.185.2022.11.04.15.29.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 15:29:52 -0700 (PDT) Date: Fri, 4 Nov 2022 22:29:48 +0000 From: Sean Christopherson To: Chao Peng Cc: Fuad Tabba , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 4/8] KVM: Use gfn instead of hva for mmu_notifier_retry Message-ID: References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-5-chao.p.peng@linux.intel.com> <20221104022813.GA4129873@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221104022813.GA4129873@chaop.bj.intel.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667600994; a=rsa-sha256; cv=none; b=UtX+hFAc/lZnZGyqWXhv2Kw8WBXfThaSnsOwQ7H+SJVElUOM9wW4zsqvZCCuphV1fS1m2P krc3+2URSL5Jb5OEK1p0alnrBJOfxpgaRh+0rzm2HVexrhlzY8XLtCCMmSH8G6VYif+V1c RYJupEFz4OLrnRvaA0kq7rDKxD6BNO8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dKOKOca6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of seanjc@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=seanjc@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667600994; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Aq/mVWfLwMWGNt8fSCRAZ8qaQX+Rp9/roFUUSHdFcg=; b=6M5r50KzmB2pVGQIJ3o0YJeRuUise/JWL8e4ng4xayyNEF2qlit/jp7Wt9lM6SSqV9eoDy axnPEBPe169MSDfH5WtPSYcruS3xSLqe8GAeKybI2cqd407SeKhBEjuDz/II3wsCI9LIIL TVHc2YHVJI6krNWAN2MM/pfzQJ4iFEE= X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 437D71A0002 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dKOKOca6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of seanjc@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=seanjc@google.com X-Stat-Signature: d6djhjjaknrrbd4ss61i8tkb7deo4ups X-HE-Tag: 1667600994-46648 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Nov 04, 2022, Chao Peng wrote: > On Thu, Oct 27, 2022 at 11:29:14AM +0100, Fuad Tabba wrote: > > Hi, > > > > On Tue, Oct 25, 2022 at 4:19 PM Chao Peng wrote: > > > > > > Currently in mmu_notifier validate path, hva range is recorded and then > > > checked against in the mmu_notifier_retry_hva() of the page fault path. > > > However, for the to be introduced private memory, a page fault may not > > > have a hva associated, checking gfn(gpa) makes more sense. > > > > > > For existing non private memory case, gfn is expected to continue to > > > work. The only downside is when aliasing multiple gfns to a single hva, > > > the current algorithm of checking multiple ranges could result in a much > > > larger range being rejected. Such aliasing should be uncommon, so the > > > impact is expected small. > > > > > > It also fixes a bug in kvm_zap_gfn_range() which has already been using > > > > nit: Now it's kvm_unmap_gfn_range(). > > Forgot to mention: the bug is still with kvm_zap_gfn_range(). It calls > kvm_mmu_invalidate_begin/end with a gfn range but before this series > kvm_mmu_invalidate_begin/end actually accept a hva range. Note it's > unrelated to whether we use kvm_zap_gfn_range() or kvm_unmap_gfn_range() > in the following patch (patch 05). Grr, in the future, if you find an existing bug, please send a patch. At the very least, report the bug. The APICv case that this was added for could very well be broken because of this, and the resulting failures would be an absolute nightmare to debug. Compile tested only... -- From: Sean Christopherson Date: Fri, 4 Nov 2022 22:20:33 +0000 Subject: [PATCH] KVM: x86/mmu: Block all page faults during kvm_zap_gfn_range() When zapping a GFN range, pass 0 => ALL_ONES for the to-be-invalidated range to effectively block all page faults while the zap is in-progress. The invalidation helpers take a host virtual address, whereas zapping a GFN obviously provides a guest physical address and with the wrong unit of measurement (frame vs. byte). Alternatively, KVM could walk all memslots to get the associated HVAs, but thanks to SMM, that would require multiple lookups. And practically speaking, kvm_zap_gfn_range() usage is quite rare and not a hot path, e.g. MTRR and CR0.CD are almost guaranteed to be done only on vCPU0 during boot, and APICv inhibits are similarly infrequent operations. Fixes: edb298c663fc ("KVM: x86/mmu: bump mmu notifier count in kvm_zap_gfn_range") Cc: stable@vger.kernel.org Cc: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 6f81539061d6..1ccb769f62af 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6056,7 +6056,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) write_lock(&kvm->mmu_lock); - kvm_mmu_invalidate_begin(kvm, gfn_start, gfn_end); + kvm_mmu_invalidate_begin(kvm, 0, -1ul); flush = kvm_rmap_zap_gfn_range(kvm, gfn_start, gfn_end); @@ -6070,7 +6070,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) kvm_flush_remote_tlbs_with_address(kvm, gfn_start, gfn_end - gfn_start); - kvm_mmu_invalidate_end(kvm, gfn_start, gfn_end); + kvm_mmu_invalidate_end(kvm, 0, -1ul); write_unlock(&kvm->mmu_lock); } base-commit: c12879206e47730ff5ab255bbf625b28ade4028f --