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 131A8C433EF for ; Tue, 21 Dec 2021 08:40:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235701AbhLUIkF (ORCPT ); Tue, 21 Dec 2021 03:40:05 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:55226 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232357AbhLUIkE (ORCPT ); Tue, 21 Dec 2021 03:40:04 -0500 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 85DBFB81202 for ; Tue, 21 Dec 2021 08:40:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3960DC36AE7; Tue, 21 Dec 2021 08:40:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640076002; bh=6n2t4Pul4m76//01Vv7UUMgTMNHDNpFfmgUjueXm2HQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yh73MDKYBgDSAFOHl8LPE0jo1hbbT+H+XTpyY9vfkkipEHCLMAwtET+I4AdXTX9MS jLFKgkvjNqT9Q4z7WQngC7ERoMnWnHJN4IPWPboZSkj3b9/k1hKJAGDjzFVmkmsvWT S1JqiH/ITg2Yb4c80HZXBV6xJtcIwR37Oj3G4Wd49lJ58qFIYiQ0c7D0hj0jkd6XAP JGGfPouX7+DibmySqQvSUg1y9mrvsMv8WZeFAOY8vlHO47hJmIlgSJBX6hn+WrgYk2 JProUppnsYv5iy/1B/8n3tOYDUNCAeby4Kq59gpLb01lK6iY1KPkkLuq4V72HqeXLR 18q6U/4SP9EUw== 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 1mzagh-00DTu5-EL; Tue, 21 Dec 2021 08:39:59 +0000 Date: Tue, 21 Dec 2021 08:39:58 +0000 Message-ID: <871r26wdup.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: References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-19-maz@kernel.org> <13046e57-b7e5-7f0b-15bd-38c09e21807a@os.amperecomputing.com> <87lf0fwsj5.wl-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/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 Tue, 21 Dec 2021 07:12:36 +0000, Ganapatrao Kulkarni wrote: > > > > On 20-12-2021 02:40 pm, Marc Zyngier wrote: > > 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). > > > > OK got it, this is to deal with Non-VHE case. No, you'd have the exact same thing with a VHE guest itself running an EL1 guest. You really cannot distinguish the two cases. In general, you can't really think the NV support in terms of VHE or nVHE, or even in terms of guest level. You need to think in terms of a single machine with three exception levels, and follow the rules of the architecture to the letter. Thanks, M. -- Without deviation from the norm, progress is not possible.