From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4285B63A for ; Thu, 9 Feb 2023 06:02:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675922549; h=from:from:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UjcQ+4IokvYePnk02ddluabPto+jaXi4Bi+pusqGeYU=; b=cYHBwT6TvLm/8SC+4n0qO5nj3zkhBhqpJoU73zvcLw/8SX5xhVzZElsgnnDiTbMTDuFsWd JIQWCbkKqeo9bHgZjw7t0lh2WYLRs5gmsAbKMYYWSk0tDa/AkGbH9xbmxyxWHRV62xpKJa QSl2KO9hT2pIoknxmcBsub1TJujFUGo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-81-hhR_7v9xOuaCxmOxWE2_wA-1; Thu, 09 Feb 2023 01:02:27 -0500 X-MC-Unique: hhR_7v9xOuaCxmOxWE2_wA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 70179800B23; Thu, 9 Feb 2023 06:02:26 +0000 (UTC) Received: from [10.64.54.63] (vpn2-54-63.bne.redhat.com [10.64.54.63]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4478F2026D4B; Thu, 9 Feb 2023 06:02:19 +0000 (UTC) Reply-To: Gavin Shan Subject: Re: [PATCH v2 05/12] KVM: arm64: Refactor kvm_arch_commit_memory_region() To: Ricardo Koller , pbonzini@redhat.com, maz@kernel.org, oupton@google.com, yuzenghui@huawei.com, dmatlack@google.com Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, qperret@google.com, catalin.marinas@arm.com, andrew.jones@linux.dev, seanjc@google.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, eric.auger@redhat.com, reijiw@google.com, rananta@google.com, bgardon@google.com, ricarkol@gmail.com References: <20230206165851.3106338-1-ricarkol@google.com> <20230206165851.3106338-6-ricarkol@google.com> From: Gavin Shan Message-ID: <8be5c7be-fd43-86e8-6b3d-6085dd4f3cc6@redhat.com> Date: Thu, 9 Feb 2023 17:02:17 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20230206165851.3106338-6-ricarkol@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Hi Ricardo, On 2/7/23 3:58 AM, Ricardo Koller wrote: > Refactor kvm_arch_commit_memory_region() as a preparation for a future > commit to look cleaner and more understandable. Also, it looks more > like its x86 counterpart (in kvm_mmu_slot_apply_flags()). > > No functional change intended. > > Signed-off-by: Ricardo Koller > --- > arch/arm64/kvm/mmu.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 9bd3c2cfb476..d2c5e6992459 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1761,20 +1761,27 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, > const struct kvm_memory_slot *new, > enum kvm_mr_change change) > { > + bool log_dirty_pages = new && new->flags & KVM_MEM_LOG_DIRTY_PAGES; > + > /* > * At this point memslot has been committed and there is an > * allocated dirty_bitmap[], dirty pages will be tracked while the > * memory slot is write protected. > */ > - if (change != KVM_MR_DELETE && new->flags & KVM_MEM_LOG_DIRTY_PAGES) { > + if (log_dirty_pages) { > + > + if (change == KVM_MR_DELETE) > + return; > + When @change is KVM_MR_DELETE, @new should be NULL. It means this check isn't needed? > /* > * If we're with initial-all-set, we don't need to write > * protect any pages because they're all reported as dirty. > * Huge pages and normal pages will be write protect gradually. > */ > - if (!kvm_dirty_log_manual_protect_and_init_set(kvm)) { > - kvm_mmu_wp_memory_region(kvm, new->id); > - } > + if (kvm_dirty_log_manual_protect_and_init_set(kvm)) > + return; > + > + kvm_mmu_wp_memory_region(kvm, new->id); > } > } > Thanks, Gavin