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 25B5EC02183 for ; Fri, 17 Jan 2025 15:45:42 +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-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Uoo0UU2S8yZCkaXWn18xyf6FOg1I/clfse8L1KxQErg=; b=fplLBzvPrGdmtdPFvzdKeXtD7r jZ27ZqW9esgqzc7av+WT5Y+VaQJOgXWcJZ5X0U2UlWhRBoTITg0gV9BOJIl0J/EtLujfamlLOyXd8 RwLKdh0sTJdit7F2shS9JumDJVKl/Ka8xvckRGvWbPi3dYT1mUtBki2W4HeiX7L4t4QFl46cEaUn9 Z7hwM6t8SqUkQV+QaOutY8K3d5O5x6bNTr0JFnw9W9+cQTAnW0B7StDX51PX5X7eLg9zE4jwEsMi+ Ue8OcZl/gXiVx0CglpC1T7Uf9Ly8JPJrVrJp7cFLDVbygF5uw7K50cbvQEVBkz98p/sGUmo2LkK55 dPZz71OA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tYoXJ-00000000eoF-0EBg; Fri, 17 Jan 2025 15:45:29 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tYo7o-00000000ax1-1cIa for linux-arm-kernel@lists.infradead.org; Fri, 17 Jan 2025 15:19:09 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8A75EA43142; Fri, 17 Jan 2025 15:17:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B979C4CEDD; Fri, 17 Jan 2025 15:19:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737127147; bh=7AOxCMuccgymNntQbj/et0ikbZnJWyXKUNvh4MpAzXs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PrbVfVri3RKrgzY464O7T1XWwlE8GZGBCAUfU0JRBmdgeKCpLpwfZL2VQcT0yd74w RFB+mmtRKK6EkME5FgMT1VP/IR/YH8mJqvA6ZcAaM9swgSUecTay/8uy2OmAGTcW6H x6bUblZbKVWcGelutGq2WhasMb/NpT3kmiGyU3EbIU8UA6ivUOoII52fka3J6vkNlv 0BOzCsz0vjpjjZb3SzOBtXAlsR8NX6W8/Pv9kdHnkqzwrVEXYNyFy2sfwwfjb8SK5b 6rqE0CsWytuXy9sMzCdEPRhHP3K/Twqn+H09PDUx4VDX0ldNnYKV57h2IRtZInHgfx I7VQFXzY8sADA== 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 1tYo7k-00D9zb-Ku; Fri, 17 Jan 2025 15:19:04 +0000 Date: Fri, 17 Jan 2025 15:19:03 +0000 Message-ID: <86wmetv57c.wl-maz@kernel.org> From: Marc Zyngier To: Wei-Lin Chang Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Bjorn Andersson , Christoffer Dall , Ganapatrao Kulkarni , Chase Conklin , Eric Auger Subject: Re: [PATCH v2 09/12] KVM: arm64: nv: Propagate CNTHCTL_EL2.EL1NV{P,V}CT bits In-Reply-To: References: <20241217142321.763801-1-maz@kernel.org> <20241217142321.763801-10-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/29.4 (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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: r09922117@csie.ntu.edu.tw, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, andersson@kernel.org, christoffer.dall@arm.com, gankulkarni@os.amperecomputing.com, chase.conklin@arm.com, eauger@redhat.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-20250117_071908_546234_118BBF24 X-CRM114-Status: GOOD ( 31.75 ) 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, 06 Jan 2025 02:33:39 +0000, Wei-Lin Chang wrote: > > Hi Marc and other KVM ARM developers, > > I have a question while learning about NV and reading the code: > > On Tue, Dec 17, 2024 at 02:23:17PM +0000, Marc Zyngier wrote: > > Allow a guest hypervisor to trap accesses to CNT{P,V}CT_EL02 by > > propagating these trap bits to the host trap configuration. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/arch_timer.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c > > index 6f04f31c0a7f2..e5951e6eaf236 100644 > > --- a/arch/arm64/kvm/arch_timer.c > > +++ b/arch/arm64/kvm/arch_timer.c > > @@ -824,6 +824,10 @@ static void timer_set_traps(struct kvm_vcpu *vcpu, struct timer_map *map) > > * Apply the enable bits that the guest hypervisor has requested for > > * its own guest. We can only add traps that wouldn't have been set > > * above. > > + * Implementation choices: we do not support NV when E2H=0 in the > > + * guest, and we don't support configuration where E2H is writable > > + * by the guest (either FEAT_VHE or FEAT_E2H0 is implemented, but > > + * not both). This simplifies the handling of the EL1NV* bits. > > Previously I was not aware that KVM ARM has these constraints on guest's > view of NV and E2H, so I appreciate this comment very much. However, > after digging through the code I could not find anywhere where these > constraints are enforced, for example initially I thought I would find > ID_AA64MMFR2_EL1_NV being zeroed in limit_nv_id_regs(), or HCR_NV added > to the res0 mask of HCR_EL2, base on whether FEAT_VHE or FEAT_E2H0 is > available to the guest. But seems like in these places the code applies > constraints looking at the host's capabilities, not the guest's. > Do you mind providing some pointers for me to investigate the code mode? Where have you looked? These constraints are enforced in the kvm-arm64/nv-e2h-select branch[1], which is pulled in the kvm-arm64/nv-next branch[2]. The NV support is split in discrete series in order to make things easier to review, but you need to have seen them all to somehow connect the dots. HTH, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv-e2h-select [2] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv-next -- Without deviation from the norm, progress is not possible.