From patchwork Thu Jul 27 07:14:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 9866371 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B9FC1603FA for ; Thu, 27 Jul 2017 07:15:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A813C287EE for ; Thu, 27 Jul 2017 07:15:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9CBB0287ED; Thu, 27 Jul 2017 07:15:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0D21A287F2 for ; Thu, 27 Jul 2017 07:15:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FeqU7I3+ReLco4sPIcTU+x3B0rF6yTbhPaulFzUCrKA=; b=LMXmioEkrua4kR wx0kXOCvJBjbTrXLOki+ISL0B0vlBNgirgfv95DQM9dL/vxrRBWaBtpYhFQlpxe7H6slrTSMg9Ms5 eSriuYV7+mfIHC3nCwuO9jdaGNHaCBmrmwpK8J7chkYlht5BqAU3tHPInqsaI4CDPTyFuI5eCTByX 5kzNDLA1BNgsugoPsEgZTMDRmBQzJSV+L1MV0ichrs9m+ReDxfEatAj6pFCT7HI5x5eUD+Nnrd1DI CEfNlzLP0F257aaDsXK2fyuY+mlqAjZj6/sSPvNyijAUlJkLBuBc18s0esoLfYZA72ZJYQVoxBAYL 8zNgCLWRAyJ6wfqN6D5g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dad0l-0005zz-N8; Thu, 27 Jul 2017 07:15:07 +0000 Received: from mail-lf0-x230.google.com ([2a00:1450:4010:c07::230]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dad0h-0005Cz-1W for linux-arm-kernel@lists.infradead.org; Thu, 27 Jul 2017 07:15:05 +0000 Received: by mail-lf0-x230.google.com with SMTP id g25so72874412lfh.1 for ; Thu, 27 Jul 2017 00:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=o9+wkzUBfXssSoJgetHq2gwbKuh4+FUayUJmdEPsq9I=; b=aOuYA5DNcES+/g0o5Ww0zpV4S8cAKCnfqoDO5rWPULoNax6tR9RUynuXOwzxW10XH2 YaUv/LCBhjP4QpQFayXJqDXS2OAH9iS5nFcQRNMPJVcK4CKyrRgBVYcKnK5YBoyiLico vtJMHOw0JsBiQlUO79zX7WruAJM1hZoAvqQ5M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=o9+wkzUBfXssSoJgetHq2gwbKuh4+FUayUJmdEPsq9I=; b=MEofGBOZvGn/lP7XXlBuFTUCXqttxZXW7PERzZx5k0CkmjXQNrHXXd8lJDaRtcTvwW I0GXPPiPoMXJMHLXx4X/PN0BPfcBHVHc4vZDmvQncyzZlqCgNUs2PvTa+66iU8sh9g/v T8Bc1sFP46SKaNJRFJZe7mWR+OGoRdijAP4Gpw+8PFzBGNqq5Ima7yUDCgIov+mww6Ah /UNijOfKBGaBQfZwqfk2yk1SNHT6OEeAUVRBPn4f+0dTjLYaXJ8YhVOWkAv8eCqzMiz0 c5SyVbikD0kqcWrf+1nZNGE/5y8sd2uJIORoAa5mbzENdpZTxClma0Ut7wRgHY7YsXVX EDlA== X-Gm-Message-State: AIVw110OSTnzUGPdcuPVQgRNyfgetNCjyjeFJyHl6ml4WcKQhFBYBfBH bonUB9+5G+i/PKoo X-Received: by 10.46.21.8 with SMTP id s8mr1215591ljd.147.1501139674112; Thu, 27 Jul 2017 00:14:34 -0700 (PDT) Received: from localhost (109.56.185.219.mobile.3.dk. [109.56.185.219]) by smtp.gmail.com with ESMTPSA id u78sm3533410lfg.93.2017.07.27.00.14.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 00:14:33 -0700 (PDT) Date: Thu, 27 Jul 2017 00:14:29 -0700 From: Christoffer Dall To: Will Deacon Subject: Re: [RFC PATCH v2 02/19] arm64: Use the physical counter when available for read_cycles Message-ID: <20170727071429.GA1432@lvm> References: <20170717142718.13853-1-cdall@linaro.org> <20170717142718.13853-3-cdall@linaro.org> <20170725094308.GC23359@arm.com> <20170725143647.GC1588@lvm> <20170726171728.GB18154@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170726171728.GB18154@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170727_001503_277215_7D265277 X-CRM114-Status: GOOD ( 40.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Christoffer Dall , kvm@vger.kernel.org, Marc Zyngier , Catalin Marinas , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Jul 26, 2017 at 06:17:29PM +0100, Will Deacon wrote: > On Tue, Jul 25, 2017 at 07:36:47AM -0700, Christoffer Dall wrote: > > On Tue, Jul 25, 2017 at 10:43:08AM +0100, Will Deacon wrote: > > > On Mon, Jul 17, 2017 at 04:27:01PM +0200, Christoffer Dall wrote: > > > > Currently get_cycles() is hardwired to arch_counter_get_cntvct() on > > > > arm64, but as we move to using the physical timer for the in-kernel > > > > time-keeping, we need to make that more flexible. > > > > > > > > First, we need to make sure the physical counter can be read on equal > > > > terms to the virtual counter, which includes adding physical counter > > > > read functions for timers that require errata. > > > > > > > > Second, we need to make a choice between reading the physical vs virtual > > > > counter, depending on which timer is used for time keeping in the kernel > > > > otherwise. We can do this using a static key to avoid a performance > > > > penalty during runtime when reading the counter. > > > > > > > > Cc: Catalin Marinas > > > > Cc: Will Deacon > > > > Cc: Mark Rutland > > > > Cc: Marc Zyngier > > > > Signed-off-by: Christoffer Dall > > > > --- > > > > arch/arm64/include/asm/arch_timer.h | 18 ++++++++++++------ > > > > arch/arm64/include/asm/timex.h | 2 +- > > > > drivers/clocksource/arm_arch_timer.c | 32 ++++++++++++++++++++++++++++++-- > > > > 3 files changed, 43 insertions(+), 9 deletions(-) > > > > > > [...] > > > > > > > @@ -886,10 +912,12 @@ static void __init arch_counter_register(unsigned type) > > > > > > > > /* Register the CP15 based counter if we have one */ > > > > if (type & ARCH_TIMER_TYPE_CP15) { > > > > - if (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) > > > > + if (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) { > > > > arch_timer_read_counter = arch_counter_get_cntvct; > > > > - else > > > > + } else { > > > > arch_timer_read_counter = arch_counter_get_cntpct; > > > > + static_branch_enable(&arch_timer_phys_counter_available); > > > > + } > > > > > > I'm a bit worried about this change, although I can't put my finger on > > > exactly the problematic scenario. My concern is that if we have a system > > > where the host kernel is entered at NS-EL1 (because, e.g. EL2 is used for > > > something else or the bootloader just didn't load us there) then the booting > > > protocol doesn't mandate a zero-initialised CNTVOFF value. If we can > > > subsequently end up using the physical counter in the kernel and the virtual > > > counter in userspace, the vDSO will get confused because the datapage values > > > will not correspond to the values it actually ends up reading. > > > > Just so I'm sure I'm understanding correctly, vDSO always reads the > > virtual counter? > > Yes, that's right. > > > > There's also > > > the likelihood that existing EL2 init code simply isn't setting up > > > CNTHCTL_EL2 and CNTVOFF correctly, so we probably need a way to force > > > virtual counter on the cmdline. > > > > My understanding was that we only ever use the physical counter when we > > boot at EL2 and therefore the kernel is in control of CNTVOFF and can > > set that to 0. Is this not the case, or are you asking for a way to > > mandate this relationship or make it abundantly clear? > > AFAICT, arch_timer_ppi_nr could return ARCH_TIMER_PHYS_NONSECURE_PPI > or ARCH_TIMER_PHYS_SECURE_PPI when we're not running at EL2, which would > cause us to use the physical counter with your patch applied. > With patch 1, yes. How about simply adding something like this then: > > Also, are you fine with arch_timer_read_counter changing to using the > > physical counter on arm64, but you're merely worried about > > read_cycles()? > > Assuming you mean get_cycles(), Yes, I should change that in the patch subject as well. > then no, I'm not worried about that because > it's just used for things like small delta calculations and entropy. ok, I was a bit confused becasue this patch only changes get_cycles(), where the previous patch changes what arch_timer_read_counter() does. > I'm > worried about the timekeeper (which I think uses arch_timer_read_counter) > being based on the physical counter and the vDSO being based on the virtual > counter and CNTVOFF != 0. > ok, so with the above proposed modification we'll maintain that CNTVOFF == 0 whenever we're not in VCPU context and the timekeeper will always use the physical counter. [...] > > > > How does this change affect the 32-bit side? All this should do is > > enable a static branch which is unused on the 32-bit side; what am I > > missing? > > The PPI selection is more complicated for 32-bit, because of the > "arm,cpu-registers-not-fw-configured" quirk. > ok, but I don't see how my two patches here affect the 32-bit side, as I only change the logic on the arm64 side? Thanks, -Christoffer diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index f4e7261..b0426ac 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -912,7 +912,8 @@ static void __init arch_counter_register(unsigned type) /* Register the CP15 based counter if we have one */ if (type & ARCH_TIMER_TYPE_CP15) { - if (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) { + if (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI || + (!is_hyp_mode_available() && IS_ENABLED(CONFIG_ARM64))) { arch_timer_read_counter = arch_counter_get_cntvct; } else { arch_timer_read_counter = arch_counter_get_cntpct;