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 78EA7C2D0CD for ; Mon, 19 May 2025 07:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type: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=ud0bfFxC8Gxw5d9VcJBlfTpRkEMLget3hZ7Og/mZPYQ=; b=hj0XFMRhorMQdFh7rNibAlxNn8 gSDP9RDDcX3xOH+scZEnsW4QZe+/Ei8TXexSEm0Cip1g/Pc5c+Yz5Wt4IDmR+A+5P4W2brRv4y8Gx RyJXDNLPCuLX41wUiTFT0TsGaVt/CR7Hh0DrurZ8E97/8uw6879Rv0JPwfsi5UqXpA/BLhCXVB0kN Eq9cXc8PhJswDMKU3C8TlPmbMZddqHH3fkrYAMzINhEKEy6UuEO2DeklrHY2bZUBB23MIUsvlv48K v8MBeOhguCSD5ZT7cWfUkIFLr/RMjww3pvTsxiwbcNcK5z0U8slWG5Zl9BZy9exdZ/pEUaZd7geUU Bs7ciViw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uGuho-00000008C9y-1O8r; Mon, 19 May 2025 07:14:36 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uGufl-00000008BnP-0aW9 for linux-arm-kernel@lists.infradead.org; Mon, 19 May 2025 07:12:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2B17E5C4B9E; Mon, 19 May 2025 07:10:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CADEC4CEE4; Mon, 19 May 2025 07:12:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747638748; bh=berpNQksN4I5+X+UnGQ86pZZ6eKvZ+gP0gHo+g2EPzI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TuiWXUBGZsSZbyblobntkQU4Wznr+TWCnb5Om/fbKKu4Wj/tkEJ8hkh/bVtxH/lBj hQOY0ES7+kWcdPF+KPPeWd27Y29lpI/p24NIJwwX9Url6vJX0ydoZovy0bEV5a3uVv GiOS5dCJycbaIk03zOBEgzTT2f/rkfaApk7IHg+r1Rwkp7fCLYrPQB0X+hhlmcA/0C MDYeb6+PzLD4iEv0kOcjjD6pk9DbwFBTpfqpAgfBeDTURvf/5bdboag/qM3obGDSiW f8jOtMzhVufYnX5IR+gFOeUDhA8urvnQoEaSEsTvirDgUU+VXI7qjPjvEHjMlPDIf+ 4uQtzMe1O6CTw== 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 1uGufh-00G8VH-PX; Mon, 19 May 2025 08:12:25 +0100 Date: Mon, 19 May 2025 08:12:24 +0100 Message-ID: <86y0utdqg7.wl-maz@kernel.org> From: Marc Zyngier To: Youngmin Nam Cc: Daniel Lezcano , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, junhosj.choi@samsung.com, hajun.sung@samsung.com, joonki.min@samsung.com, d7271.choe@samsung.com, jkkkkk.choi@samsung.com, jt1217.kim@samsung.com, qperret@google.com, willdeacon@google.com, dhyun.cha@samsung.com, kn_hong.choi@samsung.com, mankyum.kim@samsung.com Subject: Re: [QUESTION] arch_counter_register() restricts CNTPT access when booted in EL1, even if EL2 is supported In-Reply-To: References: <86frh4gazr.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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: youngmin.nam@samsung.com, daniel.lezcano@linaro.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, junhosj.choi@samsung.com, hajun.sung@samsung.com, joonki.min@samsung.com, d7271.choe@samsung.com, jkkkkk.choi@samsung.com, jt1217.kim@samsung.com, qperret@google.com, willdeacon@google.com, dhyun.cha@samsung.com, kn_hong.choi@samsung.com, mankyum.kim@samsung.com 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-20250519_001229_263572_D15FE14F X-CRM114-Status: GOOD ( 39.69 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 19 May 2025 02:43:49 +0100, Youngmin Nam wrote: >=20 > [1 ] > On Fri, May 16, 2025 at 10:28:56AM +0100, Marc Zyngier wrote: > > On Fri, 16 May 2025 07:53:58 +0100, > > Youngmin Nam wrote: > > >=20 > > > [1 ] > > > Hi arm arch timer experts, > > >=20 > > > While reviewing the arm_arch_timer code in Linux 6.12, > > > I noticed that the function arch_counter_register() restricts the > > > use of the physical counter (cntpct_el0) on systems where the kernel > > > is running in EL1, even if EL2 is supported and cntpct_el0 is > > > accessible. > > >=20 > > > In our case: > > > - We are not using pKVM. > > > - The kernel is booted in EL1. > > > - We disabled VIRT_PPI and explicitly selected PHYS_NONSECURE_PPI for= the timer refering to below code. > >=20 > > That's not legal. The architecture guarantees that there is a virtual > > timer and a physical timer. No ifs, no buts. > >=20 > > [...] > >=20 > > > As I understand it, `is_hyp_mode_available()` checks whether the > > > kernel booted into EL2 =E2=80=94 not whether EL2 is *supported* by the > > > hardware. > > >=20 > > > Therefore, even on systems where EL2 exists and `cntpct_el0` is > > > accessible from EL1, the kernel still forces the use of `cntvct_el0` > > > if the boot EL is EL1. > >=20 > > Yes, because it isn't architecturally valid to not have a virtual > > timer. This isn't about EL2 being present of not. The switch to the > > physical timer is purely an optimisation for KVM so that it doesn't > > have to switch the virtual timer back and forth when running a guest, > > as the virtual timer is the most likely used timer. > >=20 >=20 > Thanks for the clarification. >=20 > As a follow-up question: >=20 > We are working on a system that uses a vendor-specific hypervisor instead= of KVM. > In this setup, we also want to optimize timer virtualization overhead and= are considering using > the physical timer (CNTPT) in the host context for performance reasons, j= ust like KVM does. >=20 > Would it be acceptable (from the upstream kernel's perspective) to make a= similar switch > to the physical timer in this case ? No. Your hypervisor already has *two* private timers it can freely make use of (virtual and physical EL2 timers), and doesn't need to encroach on something that a guest (be it Linux or any other guest) relies on. The alternative is to trap and emulate the EL1 timer for the guest so that it *appears* to be functional. But that's obviously bad from a performance perspective. > Or is this kind of optimization strictly tied to KVM's internal behavior > and not something the kernel is expected to support generically? It is purely Linux/KVM specific, and only works because we own both side of that equation, meaning we can enforce whatever is required to make the two work together. This obviously isn't possible with third party software. Look at it from a different point of view: how would you make this work with, say, Windows? or MacOS? On the bright side, the architecture already gives you everything you need to implement your hypervisor. Just use it correctly. Thanks, M. --=20 Without deviation from the norm, progress is not possible.