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 CC6254B5C9; Thu, 21 Dec 2023 09:25:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e+a1SPK9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CC26C433C7; Thu, 21 Dec 2023 09:25:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703150706; bh=AYGf91U8T/JqQeT9S7bNrsfYGOsBnl13+m+5Z2NMRpE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=e+a1SPK9XQk98t/2P89QLYkpRHBpJS7KY21oexMqyE4ufnNnH1jA60n99byaXUQrG Whze4kMbMPwcMYcyZxxZthpvZeB86k4WI2aoo5qTNeHpb0hiPYhTvStJ316yvjfq6j dtlS3klVPy7VJSds3XBKmkSvuP/7RE7bHXFEPyxIYjUUoiWjQ+MzJJ2PQGgJxFGnDy JglUtTKXGsfwyIxsYSBqcJHYZBf1neH1h3xIwVrp65z5zJTs3+eRYQTEdLTc+zL4H0 Oh8HDT/FEIfnZbhUeAp76Mhb5ygZSOHs3myvlqSoNxw9Mv3cIVXXSMpG/TFhnfbsqA MM/3QxvCERuTg== 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.95) (envelope-from ) id 1rGFIc-005wSL-VG; Thu, 21 Dec 2023 09:25:03 +0000 Date: Thu, 21 Dec 2023 09:25:02 +0000 Message-ID: <86plyzaowh.wl-maz@kernel.org> From: Marc Zyngier To: Haibo Xu Cc: Haibo Xu , ajones@ventanamicro.com, Paul Walmsley , Palmer Dabbelt , Albert Ou , Paolo Bonzini , Shuah Khan , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Anup Patel , Atish Patra , Guo Ren , Mayuresh Chitale , Greentime Hu , wchen , Conor Dooley , Heiko Stuebner , Minda Chen , Samuel Holland , Jisheng Zhang , Sean Christopherson , Peter Xu , Like Xu , Vipin Sharma , Maciej Wieczor-Retman , Aaron Lewis , Thomas Huth , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm-riscv@lists.infradead.org Subject: Re: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us in arch timer test In-Reply-To: References: <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com> <8734vy832j.wl-maz@kernel.org> <87zfy5t1qt.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/29.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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: xiaobo55x@gmail.com, haibo1.xu@intel.com, ajones@ventanamicro.com, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, pbonzini@redhat.com, shuah@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, anup@brainfault.org, atishp@atishpatra.org, guoren@kernel.org, mchitale@ventanamicro.com, greentime.hu@sifive.com, waylingii@gmail.com, conor.dooley@microchip.com, heiko@sntech.de, minda.chen@starfivetech.com, samuel@sholland.org, jszhang@kernel.org, seanjc@google.com, peterx@redhat.com, likexu@tencent.com, vipinsh@google.com, maciej.wieczor-retman@intel.com, aaronlewis@google.com, thuth@redhat.com, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm-riscv@lists.infradead.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, 21 Dec 2023 02:58:40 +0000, Haibo Xu wrote: >=20 > On Wed, Dec 20, 2023 at 9:58=E2=80=AFPM Marc Zyngier wro= te: > > > > On Wed, 20 Dec 2023 13:51:24 +0000, > > Haibo Xu wrote: > > > > > > On Wed, Dec 20, 2023 at 5:00=E2=80=AFPM Marc Zyngier = wrote: > > > > > > > > On 2023-12-20 06:50, Haibo Xu wrote: > > > > > On Wed, Dec 20, 2023 at 2:22=E2=80=AFAM Marc Zyngier wrote: > > > > >> > > > > >> On Tue, 12 Dec 2023 09:31:20 +0000, > > > > >> Haibo Xu wrote: > > > > >> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h = b/tools/testing/selftests/kvm/include/timer_test.h > > > > >> > index 968257b893a7..b1d405e7157d 100644 > > > > >> > --- a/tools/testing/selftests/kvm/include/timer_test.h > > > > >> > +++ b/tools/testing/selftests/kvm/include/timer_test.h > > > > >> > @@ -22,6 +22,7 @@ struct test_args { > > > > >> > int nr_iter; > > > > >> > int timer_period_ms; > > > > >> > int migration_freq_ms; > > > > >> > + int timer_err_margin_us; > > > > >> > > > > >> ... except that you are storing it as a signed value. Some consi= stency > > > > >> wouldn't hurt, really, and would avoid issues when passing large > > > > >> values. > > > > >> > > > > > > > > > > Yes, it's more proper to use an unsigned int for the non-negative= error > > > > > margin. > > > > > Storing as signed here is just to keep the type consistent with t= hat > > > > > of timer_period_ms > > > > > since there will be '+' operation in other places. > > > > > > > > > > tools/testing/selftests/kvm/aarch64/arch_timer.c > > > > > /* Setup a timeout for the interrupt to arrive */ > > > > > udelay(msecs_to_usecs(test_args.timer_period_ms) + > > > > > test_args.timer_err_margin_us); > > > > > > > > But that's exactly why using a signed quantity is wrong. > > > > What does it mean to have a huge *negative* margin? > > > > > > > > > > Hi Marc, > > > > > > I agree that negative values are meaningless for the margin. > > > If I understand correctly, the negative margin should be filtered by > > > assertion in atoi_non_negative(). > > > > No. Please. > > > > atoi_non_negative() returns a uint32_t, which is what it should do. > > The bug is squarely in the use of an 'int' to store such value, and it > > is the *storage* that turns a positive value into a negative one. > > >=20 > Thanks for the detailed info! >=20 > May I understand that your concern is mainly for a platform with > 64bit int type, which may trigger the positive to negative convert? No. It specifically applies to architectures with a 32bit int type, which is... *EVERYTHING*. Here's a basic example: #include int main(int argc, char *argv[]) { int x =3D 1U << 31; printf("%d (%d)\n", x, sizeof(x)); return 0; } which returns "-2147483648 (4)" on any platform. This really is basic C, and I am very worried that you don't see the issue. I strongly suggest that you go and read about the C type system before touching this code. M. --=20 Without deviation from the norm, progress is not possible.