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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73B08C4332F for ; Sun, 6 Nov 2022 16:09:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230110AbiKFQJJ (ORCPT ); Sun, 6 Nov 2022 11:09:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229841AbiKFQJI (ORCPT ); Sun, 6 Nov 2022 11:09:08 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 211713892 for ; Sun, 6 Nov 2022 08:09:07 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 459A9B80690 for ; Sun, 6 Nov 2022 16:09:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1FA1C433D6; Sun, 6 Nov 2022 16:09:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667750943; bh=msYrpTcvZ6EtKQqrb1ppIM+/iIo+IpvgPs9nlu9+Lf4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AMBN1L/q8KvWG0yx/cmcevecVggutCYHE3VAJi2ElFTuY4w254KW8txh670m6ewJe PuCnYF2d1aApSW2xyHCAZSH0F7jAZuROYrooKCO/PsTmLwmKoj4k4NQnAjamRdi7yJ xU3vylM9uPreABqrP0BpsSvgtlpTCvkoVRd0CdU21pOx6zhfYB/whJCt7W2Q3ipZJS n8oImGO2EFtKhS2/IgbrAO2WiY2jn8ajoa0UN1b0YYy5xa+HxPK/PGbZIAq3xagumZ OGTI9xNyi2WV/oy1ofMhvxxIG7xWsBk2y1Py2f80nejxhod10XqTzW2H2/hy5fwx28 uYGCVPMD/FY8w== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1oriCj-004DYD-Il; Sun, 06 Nov 2022 16:09:01 +0000 Date: Sun, 06 Nov 2022 16:08:34 +0000 Message-ID: <87leoof4l9.wl-maz@kernel.org> From: Marc Zyngier To: Gavin Shan Cc: kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, shuah@kernel.org, catalin.marinas@arm.com, andrew.jones@linux.dev, ajones@ventanamicro.com, bgardon@google.com, dmatlack@google.com, will@kernel.org, suzuki.poulose@arm.com, alexandru.elisei@arm.com, pbonzini@redhat.com, peterx@redhat.com, seanjc@google.com, oliver.upton@linux.dev, zhenyzha@redhat.com, shan.gavin@gmail.com Subject: Re: [PATCH v8 0/7] KVM: arm64: Enable ring-based dirty memory tracking In-Reply-To: <20221104234049.25103-1-gshan@redhat.com> References: <20221104234049.25103-1-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.linux.dev, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, shuah@kernel.org, catalin.marinas@arm.com, andrew.jones@linux.dev, ajones@ventanamicro.com, bgardon@google.com, dmatlack@google.com, will@kernel.org, suzuki.poulose@arm.com, alexandru.elisei@arm.com, pbonzini@redhat.com, peterx@redhat.com, seanjc@google.com, oliver.upton@linux.dev, 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 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, 04 Nov 2022 23:40:42 +0000, Gavin Shan wrote: > > This series enables the ring-based dirty memory tracking for ARM64. > The feature has been available and enabled on x86 for a while. It > 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 series is applied to v6.1.rc3, plus commit c227590467cb ("KVM: > Check KVM_CAP_DIRTY_LOG_{RING, RING_ACQ_REL} prior to enabling them"). > The commit is currently in Marc's 'fixes' branch, targeting v6.1.rc4/5. This is starting to look good to me, and my only concerns are around the documentation and the bit of nitpicking on patch 4. If we can converge quickly on that, I'd like to queue this quickly and leave it to simmer in -next. > v7: https://lore.kernel.org/kvmarm/20221031003621.164306-1-gshan@redhat.com/ > v6: https://lore.kernel.org/kvmarm/20221011061447.131531-1-gshan@redhat.com/ > v5: https://lore.kernel.org/all/20221005004154.83502-1-gshan@redhat.com/ > v4: https://lore.kernel.org/kvmarm/20220927005439.21130-1-gshan@redhat.com/ > v3: https://lore.kernel.org/r/20220922003214.276736-1-gshan@redhat.com > v2: https://lore.kernel.org/lkml/YyiV%2Fl7O23aw5aaO@xz-m1.local/T/ > v1: https://lore.kernel.org/lkml/20220819005601.198436-1-gshan@redhat.com > > Testing > ======= > (1) kvm/selftests/dirty_log_test > (2) Live migration by QEMU Could you point to a branch that has the required QEMU changes? Thanks, M. -- Without deviation from the norm, progress is not possible.