From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E36B5492E40 for ; Mon, 21 Sep 2026 13:19:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789996790; cv=none; b=dsDEHIrFw9kU5OMfKAW7S1kJfSvn/V2bfBR8N1sk6DdlqfDSX330KNKW+GPE/jqFZvfZekXaAc7HDk9P81Fd2S8oT1n4M7/TyD81iWopMxB/OixWt5rKWAgstjyEopSVPEN6W63uyvabPA3iVWOMoZ3wimLv2QtSbCd5USMaTx4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789996790; c=relaxed/simple; bh=jPu90R1RdOAornNIigEwNsEUdl9I2dOlf5EdJ56jm1E=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ldjNi+6exHSeeUJnVOUwUIkF5kwSVM71WzznFVEK9eRu3Y0A4Uso1NIE0DXLyBnfrCK7TDfCxkGoxCNRsfMaDOh6pK9y1erfhNMisNHs9J2iVgi7S0o4URssZ18/ciZnzSEQ8bEd2tNaMj7pQggr05ZsWuIx4iGwIQHJq2vZQRY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EUu04ORn; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EUu04ORn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5691A1F000FF; Mon, 21 Sep 2026 13:19:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789996788; bh=1/+XFmmZqNE01ZjaSSHgLfLllc6A7dqNcD5RE07i+6o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=EUu04ORnMeGgS2RmbJ7hfpLpOchLTfRFSxzjii2nh1RLcPQ5xGKu2kaiapoTqDA2q 6PEbBkn8db3Gjf+sE1Mz55T4mXDbO+HZBtFUe91+Bzmux/j4Qj+qp9LZcCOhMy1ZqG i5MP3iFwoilOlxSr9W9dPvnKNO5ENT1NCaOuLChAoeJIYTXEQK+01VEqcEe+w4GvBo BSkSrbintNYcuPslKCiN+74C/1C4z6VWh0WW0BGaO9KDq3XdAbx0H4u8QOtnMYLH8I DrpwR8faj43bAQvKSTpsnTYeEc0ayxXWELxrXEDSGshEDz7wLTKWDWynvCSqlS4p9W 2eQVjQKMk3tKQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x8dvt-0000000BYJr-3F2M; Mon, 21 Sep 2026 13:19:46 +0000 Date: Mon, 21 Sep 2026 14:22:49 +0100 Message-ID: <878q4u4u3a.wl-maz@kernel.org> From: Marc Zyngier To: Zhou Wang Cc: Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , , Nianyao Tang Subject: Re: [RFC PATCH] KVM: arm64: Restrict CNTP_CVAL/CNTHP_CVAL save/reload when ptimer is used In-Reply-To: <20260921111840.3000905-1-wangzhou1@hisilicon.com> References: <20260921111840.3000905-1-wangzhou1@hisilicon.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: wangzhou1@hisilicon.com, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, kvmarm@lists.linux.dev, tangnianyao@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 21 Sep 2026 12:18:40 +0100, Zhou Wang wrote: > > A guest's physical timer may be used in nested guest or directly used in > VHE mode. We can check above cases to avoid useless CNTP_CVAL/CNTHP_CVAL save > and reload. Why useless? What cases? > > Use lazy detection to determine whether a non-nested VHE guest actually uses > the physical timer. > > timer_set_traps() initially traps CNTP_CTL_EL0 writes for non-nested guests. > On the first write that sets CNTP_CTL.ENABLE=1, the trap handler records > ptimer_used and clears the trap in CNTHCTL_EL2, allowing the guest direct > access thereafter. I really don't want to go into these micro optimisation to paper over the bad state of the architecture. The options are: - Don't use any offset (offsets always set to 0), and there will not be any trap - Use CNTPOFF, which will work just fine for an L1 guest, without traps - For nested guests, there is no solution that matches the architecture (CNTPOFF doesn't nest), and you must trap. So where is the cost in your case? > > A test result from KUT in HiSilicon HIP12 is: > > nopatch patch > hvc 758 624 > mmio_read_user 3647 3479 > mmio_read_vgic 949 817 > eoi 29 29 > ipi 2534 2302 > lpi 2684 2442 > timer_10ms 2393 2168 I don't know what these numbers are. There is no unit, no indication of how this is run (L1, L2, Ln...), no base kernel version... Can you please explain what you are actually trying to do? Are you saying that accessing the physical timer (two registers) is that expensive? Thanks, M. -- Jazz isn't dead. It just smells funny.