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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 70A99C0015E for ; Fri, 28 Jul 2023 08:12:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=q5XdURm2e+mppNuuKbWDJgaO0rFza7l9Tx+R0K2kA48=; b=KzE+ytQqgjChqa OAmvW1JVfSoRIxEErBUzRV1pukI1pGKAbEFwwvgINdq2YSn2NuxyPa8e6iSCyGZJh9zpHlZAssO0M VhJ3nMIsq2D8XaZfWSF0/utdr0e0hbt+sYAAs/AAqgX0zvTwfouzIRcmdmN/OO5z6CKYBKtJxw0Oa OoVaaF2sqKhBtAA6jVJ1Oo1mG840jPj2DbkOb0XTiyPagIqhsONLFqA3rLC6h+8FMCxOo+xdaq9+q Psi2+qpyj5fcC95smhGGJ7ya+l+ryiCwoHViVNr9uIPAzmOcp28NnZRETZHCyhBQryapVyuU31CHk SYhX99+1vcMt013RAwfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qPIZb-002LEw-2R; Fri, 28 Jul 2023 08:11:43 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qPIZH-002L7D-2M for linux-arm-kernel@lists.infradead.org; Fri, 28 Jul 2023 08:11:26 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F270761F80; Fri, 28 Jul 2023 08:11:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63C87C433C8; Fri, 28 Jul 2023 08:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690531882; bh=doFW1+C/8GMIgXMiabeS/f7ocbVsueJcERbaBXOV3hY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Oe3m3yE3SjTIG0W29iXhBxjiSWkrZ/di8Sloax8Ufbpg+5dCap2ob8B1O5GkeaZxs DWmOV43IYHTcTvAeEvPH46xnb2pBtGhZQHoc93wjMTTKEBcKl2aKSZ1SllavdmrUgY xVPY1Noa1Ofjh3TsJ2xIDZ2AD9b3qB/C8a/ceDaY9mu6giNGM65dWxWlQyyhAJrEen uEhOS8LPHKZHQ20G8SNFpzxl7hmCkaJpXfl1hrBBPFlECdDMjsN/VSGySUDTHzObjK W/wtWLAeS3Xiz0g0yINBkiu/SskU3neM6S2DfZd1sXlU9xiAgqr+/LoWv6fTLy8H33 SxzM5lcv3IgwA== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1qPIZD-00Haw9-Vc; Fri, 28 Jul 2023 09:11:20 +0100 Date: Fri, 28 Jul 2023 09:11:19 +0100 Message-ID: <87ila4qwuw.wl-maz@kernel.org> From: Marc Zyngier To: Peter Hilber Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Rutland , Daniel Lezcano , Thomas Gleixner Subject: Re: [RFC PATCH 4/7] clocksource: arm_arch_timer: Export counter type, clocksource In-Reply-To: <0290012c-a419-40ac-ed8c-7708fc5a5dd0@opensynergy.com> References: <20230630171052.985577-1-peter.hilber@opensynergy.com> <20230630171052.985577-5-peter.hilber@opensynergy.com> <874jmlza3v.wl-maz@kernel.org> <0290012c-a419-40ac-ed8c-7708fc5a5dd0@opensynergy.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/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: peter.hilber@opensynergy.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, daniel.lezcano@linaro.org, tglx@linutronix.de X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230728_011123_855767_7A981980 X-CRM114-Status: GOOD ( 47.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 27 Jul 2023 11:22:11 +0100, Peter Hilber wrote: > > On 03.07.23 10:13, Marc Zyngier wrote: > > On Fri, 30 Jun 2023 18:10:47 +0100, > > Peter Hilber wrote: > >> > >> Export helper functions to allow other code to > >> > >> - determine the counter type in use (virtual or physical, CP15 or memory), > >> > >> - get a pointer to the arm_arch_timer clocksource, which can be compared > >> with the current clocksource. > >> > >> The virtio_rtc driver will require the clocksource pointer when using > >> get_device_system_crosststamp(), and should communicate the actual Arm > >> counter type to the Virtio RTC device (cf. spec draft [1]). > > > > I really don't see why you should poke at the clocksource backend: > > > > - the MMIO clocksource is only used in PM situations, which a virtio > > driver has no business being involved with > > > > - only the virtual counter is relevant -- it is always at a 0-offset > > from the physical one when userspace has an opportunity to run > > > > So it really looks that out of the four combinations, only one is > > relevant. > > Thanks for the explanation. Dropping arch_timer_counter_get_type() and > assuming that the CP15 virtual counter is in use should also work for > now. With the physical/virtual counter distinction, I tried to be > future-proof, as per the following considerations: > > The intended consumer of arch_timer_counter_get_type() is the Virtio RTC > device (draft spec [2], patch series [1]). If the Virtio device has > optional cross-timestamp support, it must know the current Linux kernel > view of the current clocksource counter. The Virtio driver tells the > Virtio device the current counter type (in the Arm case, CNTVCT_EL0 or > CNTPCT_EL0). It is intentionally left unspecified how the Virtio device > would know the counter value. AFAIU, if the Linux kernel were a > virtualization host itself, it would be better for the Virtio device to > look at the physical counter, since the virtual counter could be set for > a guest. And in other cases, the guest OSes use a virtual counter with > an offset. The physical counter can equally be offset (and KVM does offset it), just like the virtual counter. With NV, the offsets themselves are partially under control of the guest itself. So either counters *as seen from the guest* are absolutely pointless to an observer on the host. That observer sees a virtual counter that is strictly equal to the physical counter. > This was the rationale to come up with the physical/virtual counter > distinction for the Virtio RTC device. Looking at extensions such as > FEAT_ECV, where the CNTPCT_EL0 value can depend on the EL, or FEAT_NV*, > it might be a bit simplistic. Not just simplistic. It doesn't make sense. For this to work, you'd need to know the global offset that KVM applies to the global counter, plus the *virtualised* CNTPOFF/CNTVOFF values that the guest can change at any time on a *per-CPU* basis. None of that is available outside of KVM, nor would it make any sense anyway. > Does this physical/virtual counter distinction sound like a good idea? > Otherwise I would drop the arch_timer_counter_get_type() in the next > iteration. My take on this is that only the global counter value makes any sense. That value is already available from the host as the virtual counter, because we guarantee that CNTVOFF is 0 when outside of the guest (well, technically, outside of the vcpu_load/vcpu_put section). > > > > > I'm not Cc'd on the rest of the series, so I can't even see in which > > context this is used. But as it is, the approach looks wrong. > > > > Sorry, I will Cc you on all relevant patches in the next iteration, > which I will send out soon. > > The first patch series can be found at [1]. I think the second helper > function in this patch, arch_timer_get_cs(), would still be needed, in > order to supply the clocksource to get_device_system_crosststamp(). We already have to deal with the kvm_arch_ptp_get_crosststamp() monstrosity (which I will forever regret having merged). Surely you can reuse some of that? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel