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 X-Spam-Level: X-Spam-Status: No, score=-10.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59A6AC43387 for ; Fri, 4 Jan 2019 15:50:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1C15921874 for ; Fri, 4 Jan 2019 15:50:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="gAPCM73H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C15921874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gEem579n448GsjEUKIOqGhX+W5T87B4c3rWRJnZeleQ=; b=gAPCM73Hv1IGjl l/agGETSbCtCkVtfkvQtmyL93NGhOyaO2t83iybIm+sQTnmZp70zU4mX9GvyXDj3Nd2JYMrQKIbDw 6ZcR7vCGCzsUoo9KxbhfictvO0laTGSXTDi1vzVDH3O/5CXJdsRwL/g5CnqS+X8F1JbJsrjC6uY4c lpH0PRm+L9qVFnr+dCPQs1yrYHE2K+1HC9M/T6UfvSwHsK0eurpX5w2pik4Sr7ngbdaOOBGlG5j6q VFFzpRbIJm46JL9oKvy1kiYCEoVzyU2TiDQbQ278Fq1RyPt3nUZCX7poEsMLtSP79CMWs8t+nH/1k XVyQH41xI8T95DPwsTcQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gfRk8-0000cx-3K; Fri, 04 Jan 2019 15:50:40 +0000 Received: from mga11.intel.com ([192.55.52.93]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gfRk5-0000cR-EF for linux-arm-kernel@lists.infradead.org; Fri, 04 Jan 2019 15:50:38 +0000 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2019 07:50:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,439,1539673200"; d="scan'208";a="103935317" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.154]) by orsmga007.jf.intel.com with ESMTP; 04 Jan 2019 07:50:36 -0800 Date: Fri, 4 Jan 2019 07:50:36 -0800 From: Sean Christopherson To: lantianyu1986@gmail.com Subject: Re: [PATCH 7/11] KVM: Remove redundant check in the kvm_get_dirty_log_protect() Message-ID: <20190104155036.GA11288@linux.intel.com> References: <20190104085405.40356-1-Tianyu.Lan@microsoft.com> <20190104085405.40356-8-Tianyu.Lan@microsoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190104085405.40356-8-Tianyu.Lan@microsoft.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190104_075037_494078_16362A0E X-CRM114-Status: GOOD ( 16.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: , kvm@vger.kernel.org, rkrcmar@redhat.com, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, paulus@ozlabs.org, hpa@zytor.com, kys@microsoft.com, kvmarm@lists.cs.columbia.edu, mpe@ellerman.id.au, x86@kernel.org, linux@armlinux.org.uk, michael.h.kelley@microsoft.com, mingo@redhat.com, benh@kernel.crashing.org, jhogan@kernel.org, linux-mips@vger.kernel.org, Lan Tianyu , marc.zyngier@arm.com, kvm-ppc@vger.kernel.org, bp@alien8.de, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, christoffer.dall@arm.com, ralf@linux-mips.org, paul.burton@mips.com, pbonzini@redhat.com, vkuznets@redhat.com, linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 04, 2019 at 04:54:01PM +0800, lantianyu1986@gmail.com wrote: > From: Lan Tianyu > > The dirty bits have already been checked in the previous check of > "dirty_bitmap" and mask must be non-zero value at this point. > > Signed-off-by: Lan Tianyu > --- > virt/kvm/kvm_main.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index cf7cc0554094..e75dbb15fd09 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -1206,11 +1206,9 @@ int kvm_get_dirty_log_protect(struct kvm *kvm, > mask = xchg(&dirty_bitmap[i], 0); > dirty_bitmap_buffer[i] = mask; > > - if (mask) { > - offset = i * BITS_PER_LONG; > - kvm_arch_mmu_enable_log_dirty_pt_masked(kvm, memslot, > - offset, mask); > - } > + offset = i * BITS_PER_LONG; > + kvm_arch_mmu_enable_log_dirty_pt_masked(kvm, memslot, > + offset, mask); Hmm, the check against mask was explicitly added by commit 58d2930f4ee3 ("KVM: Eliminate extra function calls in kvm_get_dirty_log_protect()"). AFAIK KVM only *sets* bits in dirty_bitmap without holding slots_lock and/or mmu_lock, so I agree that checking mask is redundant, but it'd be nice to elaborate a bit more in the changelog. At the very least this needs a Fixes tag for the aforementioned commit. Tangentially related, does mmu_lock actually need to be held while we walk dirty_bitmap in kvm_{clear,get}_dirty_log_protect()? The bitmap itself is protected by slots_lock (a lockdep assertion would be nice too), e.g. can we grab the lock iff dirty_bitmap[i] != 0? > } > spin_unlock(&kvm->mmu_lock); > } > -- > 2.14.4 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel