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 D37164218B2; Thu, 30 Apr 2026 13:14:25 +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=1777554865; cv=none; b=Fl9eICEMmncYC6AYTCqUjTrzjKRbpuSm0NqdD5dLlXfm8FiFz2+FUrvIkkaqxdc/oGS1VDvIba4YUw/b1VDu0li69XHE4zYW+sv1QzOO/LP1lAq4rNJ03U6xNVSySOpQWM5tnBBvss0/ulw4vt91buJqbFLvbIM4DLu5cCOISV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777554865; c=relaxed/simple; bh=jifMlssP5+ngMhDOU+yedkwt8RjFB3XDKVz2cX4Z3Zs=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=KRMo+5rLGtlf4DOeL+tbGzvmLEnG3WWa7MgB+kShwYi1n09ZE/0bFMVXDZs3GfQrEcSHt82RR0qOg8yTe1oYxwJxQltqzXpljciPXXomcWxWJ0eBVoX7xF5ghwvEpU534BgH5qQdION6kNhGimWY34JXvYfvmbADhGYmfdI6tRQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e0dgqLJE; 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="e0dgqLJE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62606C2BCB3; Thu, 30 Apr 2026 13:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777554865; bh=jifMlssP5+ngMhDOU+yedkwt8RjFB3XDKVz2cX4Z3Zs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=e0dgqLJEoMIzEHXFT4HqgpikyLxKMo8p8ZkYg8z2UAQSKn3ZH26iYJTczd6WOtzoD 8WEkDCs9E33Y/ZJPKxJBzpdqm8eRWTj5JcB1CBFolQ32laxj/XOuFT7FCF8dNGbWpc z29CGKcR/P/Kmwq7fikgU8Bvz9jT6Z/JUnK2aF5onaRpVAAVJskSXFOSzYgfFTvRGM Lg1G3Y4jHvfgxYgtRhtFsvJht0gKKJQ4TluwLTxmpzKzIQHnfvrykZYujvZrkIBgH7 NxxOFdSArj/Heni4c9evI+AJ1q+RzR+5HyD/0D6vMSeEKQyDZaD/wvPAw4BSN+6vOq cKs0F7d9Yz9zQ== 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 1wIRDj-0000000GHED-09B6; Thu, 30 Apr 2026 13:14:23 +0000 Date: Thu, 30 Apr 2026 14:14:22 +0100 Message-ID: <86bjf0zj2p.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: <20260430111424.3479613-2-leo.bras@arm.com> References: <20260430111424.3479613-2-leo.bras@arm.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/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 12:14:04 +0100, Leonardo Bras wrote: [...] I haven't had a chance to look at any of this yet, but just on these points: > b - checkpatch.pl keeps bothering me to add an entry in MAINTAINERS file, > and I like the idea of maintaining this. Is there any rule or > common sense on this? Should I add this entry, or should I leave it > in the arch/arm64/kvm/ general rule? No specific entry in MAINTAINERS required (or wanted). This falls into the normal KVM/arm64 maintenance. And don't worry, we know where to find you when it will come to fixing this stuff. > c - There are some trace_prink() I have left in the code, as they could > be helpful to check when HACDBS is not performing as well as it > should. Should I introduce a tracepoint instead? or just ignore it? > (it's triggered on HACDBS error, but as it falls back to software in > that case, it should not impact correctness, only performance). Debug infrastructure should be preferably *removed* altogether. trace_printk() is definitely a big no-no. > 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. > > 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... Thanks, M. -- Without deviation from the norm, progress is not possible.