From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 366F57406D; Wed, 31 Jul 2024 11:02:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423747; cv=none; b=Lv7b8/uinVy0P0NAkWL9fE15+CADONxIx+Q/H6gGDUde+YPmNhJFNYGVT8t9Kb2L8XrKWV+Aumcg8Y8UmQ6XDxgHpiA7wLjFxAYYo/BvHZTnoRDdWPXzw2mH2lf8ADEuhBturBfM3rpy2Tk6y561D2eZWtol49wb93E/zIfT+Vs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423747; c=relaxed/simple; bh=/6iywBpuRCbh4G/SNLkCIoVOg829MjsWRLVo8dy0cgA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ksrAqYx1cr+wm1f+MDRC9i5rLn/pPQ32dpiV9GdNCIzUe7aoiHbO+Y9xRS2+9CCT5sxJXMOBfV6G+8MVkZBx9ppWPuiSE5m5vroUjEWylD4jnPquZu6x94o7ec9BIJYImMhrmpPl6ZPjrpzzJJ7aCJxOkj7DJACrnzm9NSPmg/8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NMl+ymlH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NMl+ymlH" 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) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org 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: 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 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.