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 B0BB5C28CF5 for ; Wed, 26 Jan 2022 16:01:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235465AbiAZQB5 (ORCPT ); Wed, 26 Jan 2022 11:01:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235066AbiAZQBy (ORCPT ); Wed, 26 Jan 2022 11:01:54 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 365F2C06161C for ; Wed, 26 Jan 2022 08:01:54 -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 sin.source.kernel.org (Postfix) with ESMTPS id 44B96CE1E56 for ; Wed, 26 Jan 2022 16:01:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8719BC340E3; Wed, 26 Jan 2022 16:01:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643212910; bh=Zm56TX38N4k6+PcIP+qv/GJxQSw/9vyV20Gjbh9l/xI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ks+ECd1EC2NMbczzCdGXwwmsG+sn/t+c5A44Rje+RzmMjsJuWuU9VwTZHy6cvaTXQ 7iPQyhzQp9DRL8RRwjtTEZEAUIsBci2IPxExDsANpOlTybasS7rQSL6GbPkaW/OMCs Z63D+JoHwtFM/Itt6eBVHWYNhEcxVkzOc67+YYGY5oxXSOHoSdwayLv7OEGO2VZ2yc eJ0GI5MRln99zgf6tTrhSBJv4AyTb1tJqUJnVHvqdU97sbJhA+oF3ORpayCx+z5YPm dukBzj0+rqDGxOf21lhVt8wz5kkOcnRynD5amqs9danfgNBZQicl9LdGyOT02OwAmL yuOfEE8fszv/w== Received: from sofa.misterjones.org ([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 1nCkk0-003Gwb-9C; Wed, 26 Jan 2022 16:01:48 +0000 Date: Wed, 26 Jan 2022 16:01:47 +0000 Message-ID: <87a6fi7afo.wl-maz@kernel.org> From: Marc Zyngier To: "Russell King (Oracle)" Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , Ganapatrao Kulkarni , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH v5 12/69] KVM: arm64: nv: Handle HCR_EL2.NV system register traps In-Reply-To: References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-13-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: linux@armlinux.org.uk, 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, gankulkarni@os.amperecomputing.com, 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, 18 Jan 2022 15:51:30 +0000, "Russell King (Oracle)" wrote: > > On Mon, Nov 29, 2021 at 08:00:53PM +0000, Marc Zyngier wrote: > > From: Jintack Lim > > > > ARM v8.3 introduces a new bit in the HCR_EL2, which is the NV bit. When > > this bit is set, accessing EL2 registers in EL1 traps to EL2. In > > addition, executing the following instructions in EL1 will trap to EL2: > > tlbi, at, eret, and msr/mrs instructions to access SP_EL1. Most of the > > instructions that trap to EL2 with the NV bit were undef at EL1 prior to > > ARM v8.3. The only instruction that was not undef is eret. > > > > This patch sets up a handler for EL2 registers and SP_EL1 register > > accesses at EL1. The host hypervisor keeps those register values in > > memory, and will emulate their behavior. > > > > This patch doesn't set the NV bit yet. It will be set in a later patch > > once nested virtualization support is completed. > > > > Signed-off-by: Jintack Lim > > [maz: added SCTLR_EL2 RES0/RES1 handling] > > Signed-off-by: Marc Zyngier > > --- > ... > > @@ -1825,9 +1882,51 @@ static const struct sys_reg_desc sys_reg_descs[] = { > > { PMU_SYS_REG(SYS_PMCCFILTR_EL0), .access = access_pmu_evtyper, > > .reset = reset_val, .reg = PMCCFILTR_EL0, .val = 0 }, > > > > + { SYS_DESC(SYS_VPIDR_EL2), access_rw, reset_val, VPIDR_EL2, 0 }, > > + { SYS_DESC(SYS_VMPIDR_EL2), access_rw, reset_val, VMPIDR_EL2, 0 }, > > + > > + { SYS_DESC(SYS_SCTLR_EL2), access_sctlr_el2, reset_val, SCTLR_EL2, SCTLR_EL2_RES1 }, > > + { SYS_DESC(SYS_ACTLR_EL2), access_rw, reset_val, ACTLR_EL2, 0 }, > > + { SYS_DESC(SYS_HCR_EL2), access_rw, reset_val, HCR_EL2, 0 }, > > + { SYS_DESC(SYS_MDCR_EL2), access_rw, reset_val, MDCR_EL2, 0 }, > > + { SYS_DESC(SYS_CPTR_EL2), access_rw, reset_val, CPTR_EL2, CPTR_EL2_DEFAULT }, > > + { SYS_DESC(SYS_HSTR_EL2), access_rw, reset_val, HSTR_EL2, 0 }, > > + { SYS_DESC(SYS_HACR_EL2), access_rw, reset_val, HACR_EL2, 0 }, > > + > > + { SYS_DESC(SYS_TTBR0_EL2), access_rw, reset_val, TTBR0_EL2, 0 }, > > + { SYS_DESC(SYS_TTBR1_EL2), access_rw, reset_val, TTBR1_EL2, 0 }, > > + { SYS_DESC(SYS_TCR_EL2), access_rw, reset_val, TCR_EL2, TCR_EL2_RES1 }, > > + { SYS_DESC(SYS_VTTBR_EL2), access_rw, reset_val, VTTBR_EL2, 0 }, > > + { SYS_DESC(SYS_VTCR_EL2), access_rw, reset_val, VTCR_EL2, 0 }, > > + > > { SYS_DESC(SYS_DACR32_EL2), NULL, reset_unknown, DACR32_EL2 }, > > + { SYS_DESC(SYS_SPSR_EL2), access_rw, reset_val, SPSR_EL2, 0 }, > > + { SYS_DESC(SYS_ELR_EL2), access_rw, reset_val, ELR_EL2, 0 }, > > + { SYS_DESC(SYS_SP_EL1), access_sp_el1}, > > + > > { SYS_DESC(SYS_IFSR32_EL2), NULL, reset_unknown, IFSR32_EL2 }, > > + { SYS_DESC(SYS_AFSR0_EL2), access_rw, reset_val, AFSR0_EL2, 0 }, > > + { SYS_DESC(SYS_AFSR1_EL2), access_rw, reset_val, AFSR1_EL2, 0 }, > > + { SYS_DESC(SYS_ESR_EL2), access_rw, reset_val, ESR_EL2, 0 }, > > { SYS_DESC(SYS_FPEXC32_EL2), NULL, reset_val, FPEXC32_EL2, 0x700 }, > > + > > + { SYS_DESC(SYS_FAR_EL2), access_rw, reset_val, FAR_EL2, 0 }, > > + { SYS_DESC(SYS_HPFAR_EL2), access_rw, reset_val, HPFAR_EL2, 0 }, > > + > > + { SYS_DESC(SYS_MAIR_EL2), access_rw, reset_val, MAIR_EL2, 0 }, > > + { SYS_DESC(SYS_AMAIR_EL2), access_rw, reset_val, AMAIR_EL2, 0 }, > > + > > + { SYS_DESC(SYS_VBAR_EL2), access_rw, reset_val, VBAR_EL2, 0 }, > > + { SYS_DESC(SYS_RVBAR_EL2), access_rw, reset_val, RVBAR_EL2, 0 }, > > + { SYS_DESC(SYS_RMR_EL2), trap_undef }, > > + > > + { SYS_DESC(SYS_CONTEXTIDR_EL2), access_rw, reset_val, CONTEXTIDR_EL2, 0 }, > > + { SYS_DESC(SYS_TPIDR_EL2), access_rw, reset_val, TPIDR_EL2, 0 }, > > + > > + { SYS_DESC(SYS_CNTVOFF_EL2), access_rw, reset_val, CNTVOFF_EL2, 0 }, > > + { SYS_DESC(SYS_CNTHCTL_EL2), access_rw, reset_val, CNTHCTL_EL2, 0 }, > > + > > + { SYS_DESC(SYS_SP_EL2), NULL, reset_unknown, SP_EL2 }, > > Doesn't this have an effect on the ability to migrate guests between > identical hardware but running kernels with vs without this patch? > From what I remember, QEMU fails a migration if the migration target > has less system registers than the migration source. > > If so, this should at the very least be spelt out in the commit > message - it's a user experience breaking change. Maybe also preventing > the exposure of these when NV is disabled would be a good idea? Yes, that's a known issue. I have taken steps to avoid exposing these registers (the get-reg-list test now passes on a !NV system, while it didn't before). Thanks, M. -- Without deviation from the norm, progress is not possible.