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 750BB80B; Mon, 4 Aug 2025 17:57:10 +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=1754330230; cv=none; b=bc8SwrZRk4z0kKQFjxdlpPhtjIVZW0DtRVKe+dGH00A/Sm4ro8t5ngFI5MPSx8F6VzeXVjBHtr0rBJxUCsTLKzCMuZ6BqUHNqzJdG3s6LMzyVLDw/kIfs72PxlQlgNlPN6W+oBLTWIqInNNKR6PFRZYqn8iR7j2rpMeGyv8FSCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754330230; c=relaxed/simple; bh=/qem5iCywvRMvM7ds4nmEzL1HBs1rvansxua0mtBa5Y=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=i13ofgpDQh+D4sEA4Z5CHCuuvNJyTqmxDivwS4qAoiNj1tqz8I8b+xkeSwO5P+GJOecZMJJSExLorMESluTQbGys4oYK5ihL6Gfny5ykVYaO8fon3zSGmHOaHci0nF2dTHnKlE1RMdHwmcbJcuMyJRv4CvARhPsPHzOvoxHRJZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mIbX3pZM; 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="mIbX3pZM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09F0EC4CEE7; Mon, 4 Aug 2025 17:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754330230; bh=/qem5iCywvRMvM7ds4nmEzL1HBs1rvansxua0mtBa5Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mIbX3pZM4w+Y7jzmBB4a4sPYNvP1chCm4qtKtn9cC56lvo5UXweLyhis8E22WFrqz 9FXRpzYS2PmO+ntgzI5uZvy0VMKJ0pErlnLqOMVs61G+YqN4Ovx6hYxwZGnH37/Gty Lr728Kpowqg37vB5mt2H/i535V9AZpSYifGMEdtOu4SsduEdUWyFfuyM/V62u73dkU jCqtXfvDVpj342HAcJJ0iIImSENrUEv7jU8J/eOkcK3nN4bGNCf+PFgPTKcjTmzdfa nOdi8YK7lHAGYi8ngnF3ToMxwhNeVK8nAaOVqzU2DteBnAdxGhPQytdtSZGkRMEik5 gFQGRaC32jPjA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.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 1uizQp-003t2I-FJ; Mon, 04 Aug 2025 18:57:07 +0100 Date: Mon, 04 Aug 2025 18:57:07 +0100 Message-ID: <87bjovt1fw.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: Andre Przywara , Will Deacon , Julien Thierry , kvm@vger.kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH kvmtool v3 4/6] arm64: add counter offset control In-Reply-To: References: <20250729095745.3148294-1-andre.przywara@arm.com> <20250729095745.3148294-5-andre.przywara@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: kvm@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: alexandru.elisei@arm.com, andre.przywara@arm.com, will@kernel.org, julien.thierry.kdev@gmail.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 04 Aug 2025 15:45:00 +0100, Alexandru Elisei wrote: > > Hi Andre, > > You might want to capitalize the first letter of the subject line (add->Add). > > On Tue, Jul 29, 2025 at 10:57:43AM +0100, Andre Przywara wrote: > > From: Marc Zyngier > > > > KVM allows the offsetting of the global counter in order to help with > > migration of a VM. This offset applies cumulatively with the offsets > > provided by the architecture. > > > > Although kvmtool doesn't provide a way to migrate a VM, controlling > > this offset is useful to test the timer subsystem. > > > > Add the command line option --counter-offset to allow setting this value > > when creating a VM. > > Out of curiosity, how is this related to nested virtualization? Because that's the only way KVM gives you the very much required ability to offset the counters when NV is enabled. > > > > > Signed-off-by: Marc Zyngier > > Signed-off-by: Andre Przywara > > --- > > arm64/include/kvm/kvm-config-arch.h | 3 +++ > > arm64/kvm.c | 17 +++++++++++++++++ > > 2 files changed, 20 insertions(+) > > > > diff --git a/arm64/include/kvm/kvm-config-arch.h b/arm64/include/kvm/kvm-config-arch.h > > index a1dac28e6..44c43367b 100644 > > --- a/arm64/include/kvm/kvm-config-arch.h > > +++ b/arm64/include/kvm/kvm-config-arch.h > > @@ -14,6 +14,7 @@ struct kvm_config_arch { > > u64 kaslr_seed; > > enum irqchip_type irqchip; > > u64 fw_addr; > > + u64 counter_offset; > > unsigned int sve_max_vq; > > bool no_pvtime; > > }; > > @@ -59,6 +60,8 @@ int sve_vl_parser(const struct option *opt, const char *arg, int unset); > > irqchip_parser, NULL), \ > > OPT_U64('\0', "firmware-address", &(cfg)->fw_addr, \ > > "Address where firmware should be loaded"), \ > > + OPT_U64('\0', "counter-offset", &(cfg)->counter_offset, \ > > + "Specify the counter offset, defaulting to 0"), \ > > I'm having a hard time parsing this - if it's zero, then kvmtool leaves it > unset, how is the default value 0? Maybe you want to say that if left unset, > the counters behaves as if the global offset is zero. > > > OPT_BOOLEAN('\0', "nested", &(cfg)->nested_virt, \ > > "Start VCPUs in EL2 (for nested virt)"), > > > > diff --git a/arm64/kvm.c b/arm64/kvm.c > > index 23b4dab1f..6e971dd78 100644 > > --- a/arm64/kvm.c > > +++ b/arm64/kvm.c > > @@ -119,6 +119,22 @@ static void kvm__arch_enable_mte(struct kvm *kvm) > > pr_debug("MTE capability enabled"); > > } > > > > +static void kvm__arch_set_counter_offset(struct kvm *kvm) > > +{ > > + struct kvm_arm_counter_offset offset = { > > + .counter_offset = kvm->cfg.arch.counter_offset, > > + }; > > + > > + if (!kvm->cfg.arch.counter_offset) > > + return; > > + > > + if (!kvm__supports_extension(kvm, KVM_CAP_COUNTER_OFFSET)) > > + die("No support for global counter offset"); > > What happens when the user sets --counter-offset 0 and KVM doesn't support > the capability? Looks to me like instead of getting an error, kvmtool is happy > to proceed without actually setting the counter offset to 0. User might then be > fooled into thinking that KVM supports KVM_CAP_COUNTER_OFFSET, and when the same > user does --counter-offset x, they will get an error saying that there's no > support for it in KVM. I would be extremely confused by that. On a system without this extension, there is no global offset at all. So setting it to 0 or omitting the option have the exact same outcome. Why should the user care? > If this is something that you want to address, you can do it similar to > ram_addr: initialize the offset to something unreasonable before parsing the > command line parameters, and then bail early in kvm__arch_set_counter_offset(). This looks positively awful. Not to mention that on a modern system (anything >= 8.6), there is no such thing as an "unreasonable" counter value. M. -- Jazz isn't dead. It just smells funny.