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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64DA2C433F5 for ; Mon, 20 Dec 2021 09:10:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CD8554B3F4; Mon, 20 Dec 2021 04:10:46 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8QqNOeZVqNH; Mon, 20 Dec 2021 04:10:45 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A76D74B3E9; Mon, 20 Dec 2021 04:10:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1680D4B3E4 for ; Mon, 20 Dec 2021 04:10:45 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl92rszL87tL for ; Mon, 20 Dec 2021 04:10:44 -0500 (EST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E30E44B3CE for ; Mon, 20 Dec 2021 04:10:43 -0500 (EST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 35488B80E2B; Mon, 20 Dec 2021 09:10:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA1F2C36AE8; Mon, 20 Dec 2021 09:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639991440; bh=EJumnoaZeL0MRLglZLFSP0eOcfo9r/+3WUIOJDJ1E4A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qCePg3LrYhG8im9BNU0aClXtAXDhqvEBxQusPxr97oE0DEpZdrhR3bzBFbg8Lu56G yT1/RAnHyex6sbpIwMzq85AbNpv7Jc9/T7+HNYDCEKA9HWEDfaVsLqMAFHSX1Hyulp 7ZX2NuNkwo5wyAHLdMHaZtePlPm+ibE0Su82X+2O/+E9Jnjtm/OoTRcv/7IQ8ilb1c FvEyvjPy7p3sVHo4l7CtvxwFMFoZpynyUyFtYgXNSKHw7unDmUzyChxlM0PFVXSq1/ lsXDEZ7H9bghrbLirFPesSHYVcZ1cOiR+8jjHBRwaIHFbi89gP5Idh7uiqed1gMLBQ XOy92uisLw/SA== Received: from cfbb000407.r.cam.camfibre.uk ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mzEgo-00DFGF-Qz; Mon, 20 Dec 2021 09:10:38 +0000 Date: Mon, 20 Dec 2021 09:10:38 +0000 Message-ID: <87lf0fwsj5.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Subject: Re: [PATCH v5 18/69] KVM: arm64: nv: Handle virtual EL2 registers in vcpu_read/write_sys_reg() In-Reply-To: <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.com> References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-19-maz@kernel.org> <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gankulkarni@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, andre.przywara@arm.com, christoffer.dall@arm.com, jintack@cs.columbia.edu, haibo.xu@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kernel-team@android.com, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Mon, 20 Dec 2021 07:04:44 +0000, Ganapatrao Kulkarni wrote: > > > On 30-11-2021 01:30 am, Marc Zyngier wrote: > > KVM internally uses accessor functions when reading or writing the > > guest's system registers. This takes care of accessing either the stored > > copy or using the "live" EL1 system registers when the host uses VHE. > > > > With the introduction of virtual EL2 we add a bunch of EL2 system > > registers, which now must also be taken care of: > > - If the guest is running in vEL2, and we access an EL1 sysreg, we must > > revert to the stored version of that, and not use the CPU's copy. > > - If the guest is running in vEL1, and we access an EL2 sysreg, we must > > Do we have vEL1? or is it a typo? Not a typo, but only a convention (there is no such concept in the architecture). vELx denotes the exception level the guest thinks it is running at while running at EL1 (as it is the case for both vEL1 and vEL2). Depending on the exception level and the running mode (VHE or not) you emulate at any given time, you access the sysregs differently: they can be either live in the CPU, stored in memory, with or without translation. That's why I'm using these 'parallel' exception levels to denote which is which... HTH, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 872AFC433F5 for ; Mon, 20 Dec 2021 09:12:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id: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=j7lKeSaA/OhhnKoaKT3SEOgMjVRUVMCWmTttSBk27LA=; b=qVxmeGKGhQPgf+ zl1oiii0g5L3RSay/rqMQLj5rqOHey6xQ6Ihx+wkNik9fvgarz8BaKnqHo3ZMFCPP+E2ktYLzGtS+ MXlUNAsPDWWpLo+zHhZ5f47BhjvSLcRO5DAN0JHlPQSwKiQlIuRdJWaXGWxV1oniwV3hRMwepX2bU 6yqjGykxLbb7/PqR8fpy57oOz+T2sH/2/YgHB/wysDlE0Bw/3V8Mqr27EyrrPQWsml/CwZXAuy6nR faexbydkEWcKHcp+uIXtmvz6LgR3PLoQLUKzBlWAIxAuhzwfHyW48Ox5C6ThI5xMvnVOQh21tkYXG IRZk66mYT66dZoH7TB4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mzEgx-001MJi-Id; Mon, 20 Dec 2021 09:10:47 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mzEgu-001MIm-U7 for linux-arm-kernel@lists.infradead.org; Mon, 20 Dec 2021 09:10:46 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 35488B80E2B; Mon, 20 Dec 2021 09:10:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA1F2C36AE8; Mon, 20 Dec 2021 09:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639991440; bh=EJumnoaZeL0MRLglZLFSP0eOcfo9r/+3WUIOJDJ1E4A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qCePg3LrYhG8im9BNU0aClXtAXDhqvEBxQusPxr97oE0DEpZdrhR3bzBFbg8Lu56G yT1/RAnHyex6sbpIwMzq85AbNpv7Jc9/T7+HNYDCEKA9HWEDfaVsLqMAFHSX1Hyulp 7ZX2NuNkwo5wyAHLdMHaZtePlPm+ibE0Su82X+2O/+E9Jnjtm/OoTRcv/7IQ8ilb1c FvEyvjPy7p3sVHo4l7CtvxwFMFoZpynyUyFtYgXNSKHw7unDmUzyChxlM0PFVXSq1/ lsXDEZ7H9bghrbLirFPesSHYVcZ1cOiR+8jjHBRwaIHFbi89gP5Idh7uiqed1gMLBQ XOy92uisLw/SA== Received: from cfbb000407.r.cam.camfibre.uk ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mzEgo-00DFGF-Qz; Mon, 20 Dec 2021 09:10:38 +0000 Date: Mon, 20 Dec 2021 09:10:38 +0000 Message-ID: <87lf0fwsj5.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH v5 18/69] KVM: arm64: nv: Handle virtual EL2 registers in vcpu_read/write_sys_reg() In-Reply-To: <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.com> References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-19-maz@kernel.org> <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gankulkarni@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, andre.przywara@arm.com, christoffer.dall@arm.com, jintack@cs.columbia.edu, haibo.xu@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.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-20211220_011045_272859_F519F7F3 X-CRM114-Status: GOOD ( 20.19 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 20 Dec 2021 07:04:44 +0000, Ganapatrao Kulkarni wrote: > > > On 30-11-2021 01:30 am, Marc Zyngier wrote: > > KVM internally uses accessor functions when reading or writing the > > guest's system registers. This takes care of accessing either the stored > > copy or using the "live" EL1 system registers when the host uses VHE. > > > > With the introduction of virtual EL2 we add a bunch of EL2 system > > registers, which now must also be taken care of: > > - If the guest is running in vEL2, and we access an EL1 sysreg, we must > > revert to the stored version of that, and not use the CPU's copy. > > - If the guest is running in vEL1, and we access an EL2 sysreg, we must > > Do we have vEL1? or is it a typo? Not a typo, but only a convention (there is no such concept in the architecture). vELx denotes the exception level the guest thinks it is running at while running at EL1 (as it is the case for both vEL1 and vEL2). Depending on the exception level and the running mode (VHE or not) you emulate at any given time, you access the sysregs differently: they can be either live in the CPU, stored in memory, with or without translation. That's why I'm using these 'parallel' exception levels to denote which is which... HTH, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25E5EC433EF for ; Mon, 20 Dec 2021 09:10:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230036AbhLTJKo (ORCPT ); Mon, 20 Dec 2021 04:10:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229474AbhLTJKn (ORCPT ); Mon, 20 Dec 2021 04:10:43 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C1A0C061574 for ; Mon, 20 Dec 2021 01:10:43 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 34480B801B8 for ; Mon, 20 Dec 2021 09:10:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA1F2C36AE8; Mon, 20 Dec 2021 09:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639991440; bh=EJumnoaZeL0MRLglZLFSP0eOcfo9r/+3WUIOJDJ1E4A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qCePg3LrYhG8im9BNU0aClXtAXDhqvEBxQusPxr97oE0DEpZdrhR3bzBFbg8Lu56G yT1/RAnHyex6sbpIwMzq85AbNpv7Jc9/T7+HNYDCEKA9HWEDfaVsLqMAFHSX1Hyulp 7ZX2NuNkwo5wyAHLdMHaZtePlPm+ibE0Su82X+2O/+E9Jnjtm/OoTRcv/7IQ8ilb1c FvEyvjPy7p3sVHo4l7CtvxwFMFoZpynyUyFtYgXNSKHw7unDmUzyChxlM0PFVXSq1/ lsXDEZ7H9bghrbLirFPesSHYVcZ1cOiR+8jjHBRwaIHFbi89gP5Idh7uiqed1gMLBQ XOy92uisLw/SA== Received: from cfbb000407.r.cam.camfibre.uk ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mzEgo-00DFGF-Qz; Mon, 20 Dec 2021 09:10:38 +0000 Date: Mon, 20 Dec 2021 09:10:38 +0000 Message-ID: <87lf0fwsj5.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH v5 18/69] KVM: arm64: nv: Handle virtual EL2 registers in vcpu_read/write_sys_reg() In-Reply-To: <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.com> References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-19-maz@kernel.org> <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.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/27.1 (x86_64-pc-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: gankulkarni@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, andre.przywara@arm.com, christoffer.dall@arm.com, jintack@cs.columbia.edu, haibo.xu@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, 20 Dec 2021 07:04:44 +0000, Ganapatrao Kulkarni wrote: > > > On 30-11-2021 01:30 am, Marc Zyngier wrote: > > KVM internally uses accessor functions when reading or writing the > > guest's system registers. This takes care of accessing either the stored > > copy or using the "live" EL1 system registers when the host uses VHE. > > > > With the introduction of virtual EL2 we add a bunch of EL2 system > > registers, which now must also be taken care of: > > - If the guest is running in vEL2, and we access an EL1 sysreg, we must > > revert to the stored version of that, and not use the CPU's copy. > > - If the guest is running in vEL1, and we access an EL2 sysreg, we must > > Do we have vEL1? or is it a typo? Not a typo, but only a convention (there is no such concept in the architecture). vELx denotes the exception level the guest thinks it is running at while running at EL1 (as it is the case for both vEL1 and vEL2). Depending on the exception level and the running mode (VHE or not) you emulate at any given time, you access the sysregs differently: they can be either live in the CPU, stored in memory, with or without translation. That's why I'm using these 'parallel' exception levels to denote which is which... HTH, M. -- Without deviation from the norm, progress is not possible.