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 X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55070C2D0C2 for ; Fri, 3 Jan 2020 13:37:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 31E51215A4 for ; Fri, 3 Jan 2020 13:37:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727820AbgACNhY (ORCPT ); Fri, 3 Jan 2020 08:37:24 -0500 Received: from foss.arm.com ([217.140.110.172]:55670 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727543AbgACNhY (ORCPT ); Fri, 3 Jan 2020 08:37:24 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E23D7328; Fri, 3 Jan 2020 05:37:23 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 091643F237; Fri, 3 Jan 2020 05:37:22 -0800 (PST) Date: Fri, 3 Jan 2020 13:37:20 +0000 From: Andre Przywara To: Alexandru Elisei Cc: kvm@vger.kernel.org, pbonzini@redhat.com, drjones@redhat.com, maz@kernel.org, vladimir.murzin@arm.com, mark.rutland@arm.com Subject: Re: [kvm-unit-tests PATCH v3 13/18] arm64: timer: Test behavior when timer disabled or masked Message-ID: <20200103133720.05f1bfb2@donnerap.cambridge.arm.com> In-Reply-To: <1577808589-31892-14-git-send-email-alexandru.elisei@arm.com> References: <1577808589-31892-1-git-send-email-alexandru.elisei@arm.com> <1577808589-31892-14-git-send-email-alexandru.elisei@arm.com> Organization: ARM X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 31 Dec 2019 16:09:44 +0000 Alexandru Elisei wrote: Hi, > When the timer is disabled (the *_CTL_EL0.ENABLE bit is clear) or the > timer interrupt is masked at the timer level (the *_CTL_EL0.IMASK bit is > set), timer interrupts must not be pending or asserted by the VGIC. > However, only when the timer interrupt is masked, we can still check > that the timer condition is met by reading the *_CTL_EL0.ISTATUS bit. > > This test was used to discover a bug and test the fix introduced by KVM > commit 16e604a437c8 ("KVM: arm/arm64: vgic: Reevaluate level sensitive > interrupts on enable"). > > Signed-off-by: Alexandru Elisei > --- > arm/timer.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arm/timer.c b/arm/timer.c > index 67e95ede24ef..a0b57afd4fe4 100644 > --- a/arm/timer.c > +++ b/arm/timer.c > @@ -230,9 +230,17 @@ static void test_timer(struct timer_info *info) > > /* Disable the timer again and prepare to take interrupts */ > info->write_ctl(0); > + isb(); > + info->irq_received = false; > set_timer_irq_enabled(info, true); Are we too impatient here? There does not seem to be a barrier after the write to the ISENABLER register, so I wonder if we need at least a dsb() here? I think in other occasions (GIC test) we even wait for some significant amount of time to allow interrupts to trigger (or not). > + report(!info->irq_received, "no interrupt when timer is disabled"); > report(!gic_timer_pending(info), "interrupt signal no longer pending"); > > + info->write_ctl(ARCH_TIMER_CTL_ENABLE | ARCH_TIMER_CTL_IMASK); > + isb(); > + report(!gic_timer_pending(info), "interrupt signal not pending"); > + report(info->read_ctl() & ARCH_TIMER_CTL_ISTATUS, "timer condition met"); > + > report(test_cval_10msec(info), "latency within 10 ms"); > report(info->irq_received, "interrupt received"); Not part of your patch, but is this kind of evaluation of the irq_received actually valid? Does the compiler know that this gets set in another part of the code (the IRQ handler)? Do we need some synchronisation or barrier here to prevent the compiler from optimising or reordering the access to irq_received? Cheers, Andre.