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 77857C3DA7F for ; Wed, 31 Jul 2024 11:03:08 +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=s+E5huhXKmOTpp/TNt8KcZvNuaaeVcUFYBN4KDqZmG4=; b=mJZzDjYSqM1DCY/Sqjyzomvouq JoNl383wQOKi0csjAla+oSqL8bBnRqZiunYxdialPOqgtVsxQMmJ2/AK0TC3faPJr2pgGUdKNCCXk W25wYfRYA6T1CiAG+GvV5aXXDBreGWGM1Ub6jf40HfuFXJaO2Cm5iRWThaJTbl5hbVHWSdk/hZ4gW jmHkDMkzIoKRTzpBA6BthLHKoYTxxxI8kwwbohiBqDvacbqUv1yRcOgZmTcZZyrMNnIgaPG4pKrFB jNOtEvIlwmizBUAXFX2KdhhlPojam9KVC9Q9wjyM2QWwd1D0KseFqNg9fwLGCazUZFFxmr/RT45rT ke5BgaUg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZ76f-00000000p2d-3Aat; Wed, 31 Jul 2024 11:02:57 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZ76D-00000000ozo-0uNh for linux-arm-kernel@lists.infradead.org; Wed, 31 Jul 2024 11:02:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 84E7CCE13AA; Wed, 31 Jul 2024 11:02:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9171C116B1; Wed, 31 Jul 2024 11:02:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423746; bh=/6iywBpuRCbh4G/SNLkCIoVOg829MjsWRLVo8dy0cgA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NMl+ymlHcnwHjJlvlSFnthrD/4cx3W/zhGEMqjzlSYHo4MCSnsSfAGLxE9ogEP0og l/72pm4GULf0TJypVu8eIbjYPjfTzzWhUEkCExtzGmrMcRbakPBIu/4DwX2HLKOeti WH1SECjAsk6yG2yVzH0wR7TethaQgXbm0MLFzP1xUG27an4MqMNUg2BcAlV7Lu/FWu kd2H/6Y/3r4kvvx60vRA986KwRrbzP796QmSRgqg82xcO03N9bWwUoaKa3fqEG/6Hc WXxzscNQJaydYnDjYutFuri4WTKVvKWaarPopB3tcYiTXswdNImAIIuY0MdouqtsaK b11eLOdg/5Rhg== 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 1sZ768-00Gxqw-TI; Wed, 31 Jul 2024 12:02:25 +0100 Date: Wed, 31 Jul 2024 12:02:24 +0100 Message-ID: <86sevp25a7.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Joey Gouly Subject: Re: [PATCH 00/12] KVM: arm64: nv: Add support for address translation instructions In-Reply-To: References: <20240625133508.259829-1-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.3 (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: alexandru.elisei@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, joey.gouly@arm.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-20240731_040229_651345_A531C383 X-CRM114-Status: GOOD ( 30.78 ) 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 Wed, 31 Jul 2024 11:05:05 +0100, Alexandru Elisei wrote: > > Hi Marc, > > On Tue, Jun 25, 2024 at 02:34:59PM +0100, Marc Zyngier wrote: > > Another task that a hypervisor supporting NV on arm64 has to deal with > > is to emulate the AT instruction, because we multiplex all the S1 > > translations on a single set of registers, and the guest S2 is never > > truly resident on the CPU. > > I'm unfamiliar with the state of NV support in KVM, but I thought I would have a > look at when AT trapping is enabled. As far as I can tell, it's only enabled in > vhe/switch.c::__activate_traps() -> compute_hcr() if is_hyp_ctct(vcpu). Found > this by grep'ing for HCR_AT. > > Assuming the above is correct, I am curious about the following: > > - The above paragraph mentions guest's stage 2 (and the code takes that into > consideration), yet when is_hyp_ctxt() is true it is likely that the guest > stage 2 is not enabled. Are you planning to enable the AT trap based on > virtual HCR_EL2.VM being set in a later series? I don't understand what you are referring to. AT traps and the guest's HCR_EL2.VM are totally orthogonal, and are (or at least should be) treated independently. But more importantly, there are a bunch of cases where you have no other choice but trap, and that what I allude to when I say "because we multiplex all the S1 translations on a single set of register". If I'm running the EL2 part of the guest, and that guest executes an AT S1E1R while HCR_EL2.{E2H,TGE}={1,0}, it refers to the guest's EL1&0 translation regime. I can't let the guest execute it, because it would walk its view of the EL2&0 regime. So we need to trap, evaluate what the guest is trying to do, and do the walk in the correct context (by using the instructions or the SW walk). > > - A guest might also set the HCR_EL2.AT bit in the virtual HCR_EL2 register. I > suppose I have the same question, injecting the exception back into the guest > is going to be handled in another series? This is already handled. The guest's HCR_EL2 is always folded into the runtime configuration, and the resulting trap handled through the existing trap routing infrastructure (see d0fc0a2519a6d, which added the triaging of most traps resulting from HCR_EL2). Thanks, M. -- Without deviation from the norm, progress is not possible.