Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1332738rwb; Fri, 19 Aug 2022 01:34:01 -0700 (PDT) X-Google-Smtp-Source: AA6agR49Rl2X/APvlyKcrqdTOf02pFWGc3LG/kXKGltiCzmCJn6c67WFSeP01FBAJ+qNz6e0xZix X-Received: by 2002:a63:d448:0:b0:41d:d4e9:b4aa with SMTP id i8-20020a63d448000000b0041dd4e9b4aamr5289927pgj.123.1660898041157; Fri, 19 Aug 2022 01:34:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660898041; cv=none; d=google.com; s=arc-20160816; b=JTr/H7zFHKro17WLOfuXRUTk045EaaMMar7TMUP9lSfI/peFspR8WkuVZ++8MXVa7s qYPVDrbWV6U+i18gzqlZMKmLheSDuoE40dqiozDgwNwUwMDMoIx9PqkfugGcfFHbuqss tZlDXo2fh7Gl5or4hVWhFWnatri6JA1uzWZDRRiOLcR7KE3CQbMm9/OMAtWKGB1tbLvX tLTpgWTcR6Fj+wnQBaZ9gNRUkr9HXXaR9LcQR0I672Jl/yvKRFxOTTzN/RlkUjDJk1TC TvhYZ3Uu74RizjGjRJ3a8O2g39ZY1ncX4NgrEeX8Xrsi98DoIEQyYHXV1kpHPp7RUVkI ukGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=3+Uy2MhA8LS8igC1RibqUwWx7e0XBWz2VcikbtPgLBU=; b=b+DgSIdC2c8JUKI2+XBLnZU9+aFHg8JKGgCMr2vewNoGZUz4FeKUXhvgPbkANBYz7A PbFwRPJaPkGTZNk+r7/zIaNiAlKOYMXCQeaQ0Npptr4XvIn/mqPO6rVcaV6IKgdS1M78 l4XDGRpYeLTp9c7S2K9Is/B+4PZkLqbCTJ8Mc1d8PwdvaoD5XYy+1rO+BKI9jaTRehwU hMiFMm3Rwvzqg77nNTYtNWHCYB4P2b1FFdio/dU+rUng88AsuSNP7bZDD+++JKf5h7aC XodPOXM9wanMYlPmI5QOivqkOAjurgTf/7zYEQiCIvDBpu3Jn/OB9u5Lwc4unTngOKsC 868A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=bPzGRNlo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u38-20020a634566000000b004157aa8707csi3602266pgk.110.2022.08.19.01.33.49; Fri, 19 Aug 2022 01:34:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=bPzGRNlo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347349AbiHSIAc (ORCPT + 99 others); Fri, 19 Aug 2022 04:00:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347320AbiHSIAY (ORCPT ); Fri, 19 Aug 2022 04:00:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A1E71F618; Fri, 19 Aug 2022 01:00:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 65240616D4; Fri, 19 Aug 2022 08:00:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6791C433B5; Fri, 19 Aug 2022 08:00:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660896021; bh=dXB7Dmr6Olnqm8i/ag5x25/j/xOuKOYp7Zqy3xYbF1k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bPzGRNloxET7jCjbmwuPekfurJU+YIanGSes6+FQxRyOaXDN7NleDvVk0kCSGm+mj Nvy+u3VuCbER8OL+RbU4KnLqA6HRIfjiQ7u8R5gsfEHDNpnzogYoaC5TjC7KhI9nGl 3u6j0LMPpZx/z/OYomSHy1cBWXgHYDxR1vDcP0ZfPUIOgSJjWLT9uKP94QaW4rEyq0 Uw510IEA5cxLKQKuP025ixhomp3R0zWPbgu8jqG/fWOoVRppxVNpkOQSMy+fdBPeIl fYw4MU6pTlU+kolvweUV5rWvIr/LtPt8krly8NS3/oMs0OxtW71SdawKlOlX4geM01 EzczQKfP6wZiA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oOwvT-004D7a-Dh; Fri, 19 Aug 2022 09:00:19 +0100 Date: Fri, 19 Aug 2022 09:00:18 +0100 Message-ID: <87lerkwtm5.wl-maz@kernel.org> From: Marc Zyngier To: Gavin Shan Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, peterx@redhat.com, pbonzini@redhat.com, corbet@lwn.net, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org, seanjc@google.com, drjones@redhat.com, dmatlack@google.com, bgardon@google.com, ricarkol@google.com, zhenyzha@redhat.com, shan.gavin@gmail.com Subject: Re: [PATCH v1 1/5] KVM: arm64: Enable ring-based dirty memory tracking In-Reply-To: <20220819005601.198436-2-gshan@redhat.com> References: <20220819005601.198436-1-gshan@redhat.com> <20220819005601.198436-2-gshan@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gshan@redhat.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, peterx@redhat.com, pbonzini@redhat.com, corbet@lwn.net, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org, seanjc@google.com, drjones@redhat.com, dmatlack@google.com, bgardon@google.com, ricarkol@google.com, zhenyzha@redhat.com, shan.gavin@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Aug 2022 01:55:57 +0100, Gavin Shan wrote: > > The ring-based dirty memory tracking has been available and enabled > on x86 for a while. The feature is beneficial when the number of > dirty pages is small in a checkpointing system or live migration > scenario. More details can be found from fb04a1eddb1a ("KVM: X86: > Implement ring-based dirty memory tracking"). > > This enables the ring-based dirty memory tracking on ARM64. It's > notable that no extra reserved ring entries are needed on ARM64 > because the huge pages are always split into base pages when page > dirty tracking is enabled. Can you please elaborate on this? Adding a per-CPU ring of course results in extra memory allocation, so there must be a subtle x86-specific detail that I'm not aware of... > > Signed-off-by: Gavin Shan > --- > Documentation/virt/kvm/api.rst | 2 +- > arch/arm64/include/uapi/asm/kvm.h | 1 + > arch/arm64/kvm/Kconfig | 1 + > arch/arm64/kvm/arm.c | 8 ++++++++ > 4 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index abd7c32126ce..19fa1ac017ed 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -8022,7 +8022,7 @@ regardless of what has actually been exposed through the CPUID leaf. > 8.29 KVM_CAP_DIRTY_LOG_RING > --------------------------- > > -:Architectures: x86 > +:Architectures: x86, arm64 > :Parameters: args[0] - size of the dirty log ring > > KVM is capable of tracking dirty memory using ring buffers that are > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index 3bb134355874..7e04b0b8d2b2 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -43,6 +43,7 @@ > #define __KVM_HAVE_VCPU_EVENTS > > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 > +#define KVM_DIRTY_LOG_PAGE_OFFSET 64 For context, the documentation says: - if KVM_CAP_DIRTY_LOG_RING is available, a number of pages at KVM_DIRTY_LOG_PAGE_OFFSET * PAGE_SIZE. [...] What is the reason for picking this particular value? > > #define KVM_REG_SIZE(id) \ > (1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT)) > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig > index 815cc118c675..0309b2d0f2da 100644 > --- a/arch/arm64/kvm/Kconfig > +++ b/arch/arm64/kvm/Kconfig > @@ -32,6 +32,7 @@ menuconfig KVM > select KVM_VFIO > select HAVE_KVM_EVENTFD > select HAVE_KVM_IRQFD > + select HAVE_KVM_DIRTY_RING > select HAVE_KVM_MSI > select HAVE_KVM_IRQCHIP > select HAVE_KVM_IRQ_ROUTING > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 986cee6fbc7f..3de6b9b39db7 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -866,6 +866,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > if (!ret) > ret = 1; > > + /* Force vcpu exit if its dirty ring is soft-full */ > + if (unlikely(vcpu->kvm->dirty_ring_size && > + kvm_dirty_ring_soft_full(&vcpu->dirty_ring))) { > + vcpu->run->exit_reason = KVM_EXIT_DIRTY_RING_FULL; > + trace_kvm_dirty_ring_exit(vcpu); > + ret = 0; > + } > + Why can't this be moved to kvm_vcpu_exit_request() instead? I would also very much like the check to be made a common helper with x86. A seemingly approach would be to make this a request on dirty log insertion, and avoid the whole "check the log size" on every run, which adds pointless overhead to unsuspecting users (aka everyone). Thanks, M. -- Without deviation from the norm, progress is not possible.