From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 02B2F34E746; Thu, 30 Apr 2026 14:51:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777560684; cv=none; b=mWPkIqNhX/sIEnCiKXf07QyryHannEWL38iRjq1mYxSHSZxPHbjmgCMbpCKQMWJtxdhgg96MitwGiSuOMjN5yvpuq9swIFzescUpIQiWB1EIgvBQ7mNOwoBlJcEfJNmQf7q91nBWoh2FEB/9iZndbl8WiIV41b+mBFxSrYOxpKY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777560684; c=relaxed/simple; bh=F04flt0u0jeUiSYW5q5UKAs4vTOREkSTch+Sz1CLuk0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cOLVBvjyYoS9AqfmgMd1nRA47nDj2nww9IT1oINTNObpQKSXrau7DzTmhvaeOxS11JUNoAxBfhDUtr4kMJYDAT0tl4HUqUYRaP+nAzKF3/uITWVu0GUMqgcK7Kn8BhaT+8HZX3/N97wbTw4meIt5RlZfhhRmoXXn6FK08jf4KYk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N06B4eCq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N06B4eCq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B9C2C2BCB3; Thu, 30 Apr 2026 14:51:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777560683; bh=F04flt0u0jeUiSYW5q5UKAs4vTOREkSTch+Sz1CLuk0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=N06B4eCqsyK+pw6ROnfRJmBqvv47hgUyYU3hv0SxLfsuzCH4fxYZ1wmQDZ2ruXsdR oIR/l0FOsZGg2ty2hV1U1a/W9uHxkOvVDSUqRjzq0hnYQpZtGBgqwztoqou2pEC9MS y5WH0yO2QeyMqV05hlQNRaVYjji8gjkBXXSYtvI6/aIDb3Gyg7ozE8KP4Ly47lET7a dlqPSNSIsPgTtBYzFCCq/5iK9YQiENFB6sL+kThbsctiHB4bwmsN1cnJ/7Mq0kyXJC osnc32UOYzmWEvlvu7atHCyDaLBNpJ0PAvkNumGB/wBlm8sC5HRdQPqYZZ6oJpGvDu TCkuI5i9o4vsw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wISjY-0000000GIer-3eg7; Thu, 30 Apr 2026 14:51:20 +0000 Date: Thu, 30 Apr 2026 15:51:20 +0100 Message-ID: <86a4ukzel3.wl-maz@kernel.org> From: Marc Zyngier To: Leonardo Bras Cc: Catalin Marinas , Will Deacon , Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , "Rafael J. Wysocki" , Len Brown , Saket Dumbre , Paolo Bonzini , Chengwen Feng , Jonathan Cameron , Kees Cook , =?UTF-8?B?TWlr?= =?UTF-8?B?b8WCYWo=?= Lenczewski , Ryan Roberts , Yang Shi , Thomas Huth , mrigendrachaubey , Yeoreum Yun , Mark Brown , Kevin Brodsky , James Clark , Ard Biesheuvel , Fuad Tabba , Raghavendra Rao Ananta , Nathan Chancellor , Vincent Donnefort , Lorenzo Pieralisi , Sascha Bischoff , Anshuman Khandual , Tian Zheng , Wei-Lin Chang , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev, kvm@vger.kernel.org Subject: Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS) In-Reply-To: References: <20260430111424.3479613-2-leo.bras@arm.com> <86bjf0zj2p.wl-maz@kernel.org> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: leo.bras@arm.com, catalin.marinas@arm.com, will@kernel.org, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, rafael@kernel.org, lenb@kernel.org, saket.dumbre@intel.com, pbonzini@redhat.com, fengchengwen@huawei.com, jic23@kernel.org, kees@kernel.org, miko.lenczewski@arm.com, ryan.roberts@arm.com, yang@os.amperecomputing.com, thuth@redhat.com, mrigendra.chaubey@gmail.com, yeoreum.yun@arm.com, broonie@kernel.org, kevin.brodsky@arm.com, james.clark@linaro.org, ardb@kernel.org, tabba@google.com, rananta@google.com, nathan@kernel.org, vdonnefort@google.com, lpieralisi@kernel.org, Sascha.Bischoff@arm.com, anshuman.khandual@arm.com, zhengtian10@huawei.com, weilin.chang@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 30 Apr 2026 14:29:37 +0100, Leonardo Bras wrote: > > On Thu, Apr 30, 2026 at 02:14:22PM +0100, Marc Zyngier wrote: > > On Thu, 30 Apr 2026 12:14:04 +0100, > > Leonardo Bras wrote: > > > > > d - In __kvm_arch_dirty_log_clear() there is no way to predict how long > > > should be the buffer, so I used 1x PAGE_SIZE, and when it gets full > > > it's cleaned and reused. Should I let users configure that over a > > > parameter, or is it overthinking? > > > > How long is a piece of string? We can't know that. A single page feels > > very small in the 4kB case, and letting userspace define the size of > > that buffer seems a likely requirement. > > > > Ok, as a KVM parameter, or as a compile-time option? Noticed the "userspace" word in there? It *has* to be controlled by userspace one way or another. So not as a kernel parameter, and *never* as a compile option. > > > Kernel v7.0.0 + this patchset builds properly, passing both kvm selftests > > > for dirty-bit tracking[2], on HW HACDBS enabled or disabled. > > > > I have absolutely no trust in these tests. > > > > Have you enabled a VMM to make use of these APIs, and actively > > migrated running guests? That's the level of testing I'd like to see, > > as the selftests are not what people run in production... > > > > There is no enablement needed on VMM side. > Yes, I have created a VM on upstream qemu with --enable-kvm and migrated it > on the same host. (Inside a model) > > That was the first test I used, but then I found out that kvm selftests > stress up multiple scenarios in an easier way. Except when they don't. In my experience, the selftests are only there to give the CI people the fuzzy feeling that they are doing something useful. I have a collection of examples indicating that what these things test is not representative of the bugs we have in KVM. > Do you prefer me to test on any specific scenario, or does whatever qemu > uses as a default parameter work well enough? I want to hear about testing at a scale that make sense for production VMs, including live migrating between hosts while under memory pressure (swapping out). I'm also interested in efficiency: how much better is HACDBS compared to the current page faulting? Just having patches for a feature is not enough to decide adoption of that feature. Show me the benefits in a quantitative way (within the limits of the model, of course). Thanks, M. -- Without deviation from the norm, progress is not possible.