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 75608C4345F for ; Thu, 2 May 2024 15:23:27 +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=sn35QVDblSHh7OJpvQtLtJbdF1mh9sxMM9eSUbqcWCM=; b=MWDpAj0loY4TOz o7rwhSkfRmUbwfajwZS60jQtTeE8iEwmm7Dk2C230dkwT4nZdL9YAhHxF5Fc9IdLvHEEZoDkQgn0i qL8jjRoYG8t1bXoOme9Zeh7qvevTeIi9x+Jzu4uy5tQDUnmQGmu6HFv7HrCnU4tFYN2MbTnpQ8RlQ Q6E8DjgvYUKH3liufucfsqfdswGXICm7YX/RYUlQ5UP2DyJlwci42M8ddttRhq/9M+0CSdn0tjoqB AvTtsNkxvtGpytWuKrb6Y6GWffPkim1f91SvSf9G8yl7zqQDR7UpfnprsbHBvlmzo08p8g0Bxsyy4 CD9NipwPkv3P0WShqHtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2YHG-0000000D6hf-0qXW; Thu, 02 May 2024 15:23:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2YHC-0000000D6hB-0T2h for linux-arm-kernel@lists.infradead.org; Thu, 02 May 2024 15:23:15 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5992F61B69; Thu, 2 May 2024 15:23:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F243AC113CC; Thu, 2 May 2024 15:23:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714663393; bh=eApqwL8Yp0/lR4LLZsggGmuCT1LDXoRYWXxby2uNi3g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l+f33SuErm7T3rLAPGQ0qArKYs1YanipY1TRsryk7T5/2D4Vn2WjKkTyfqJ1vpSLt 9RLXRd8pISglbIqPmhrzebjQaS+f5TQPvkVujG8CsdLWBa0pfQc01HD3oTGie1Zdme mjlst1YrXxm2qnqHko8jTktpyENVKQxcs22YA63nQs7pk8HcFbGIM4Jd8RQJYGyWp/ 1pxLeX3Z5cvOzZpiz99KOqTtXBzMSN5/0khOdlT1UTof1l2VrxvP7wGHYpVAkpbACD 4EgZGe8D+BRRuiiHTK4ZDdA+yCZSSq9/q96YNSP/RMst+D/nXYFzRICPtQztu7YvHo fH6YBYeON0rKA== 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 1s2YH8-00A2NP-IE; Thu, 02 May 2024 16:23:10 +0100 Date: Thu, 02 May 2024 16:23:10 +0100 Message-ID: <865xvwqlup.wl-maz@kernel.org> From: Marc Zyngier To: "Russell King (Oracle)" Cc: Oliver Upton , Catalin Marinas , Will Deacon , James Morse , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable In-Reply-To: References: 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.2 (aarch64-unknown-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: linux@armlinux.org.uk, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev 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-20240502_082314_255395_8A5BC191 X-CRM114-Status: GOOD ( 35.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 Thu, 02 May 2024 11:50:10 +0100, "Russell King (Oracle)" wrote: > > On Wed, May 01, 2024 at 08:51:15PM +0100, Russell King (Oracle) wrote: > > On Wed, May 01, 2024 at 06:59:17PM +0000, Oliver Upton wrote: > > > On Wed, May 01, 2024 at 07:08:05PM +0100, Russell King (Oracle) wrote: > > > > On Wed, May 01, 2024 at 05:57:20PM +0000, Oliver Upton wrote: > > > > > Hi Russell, > > > > > > > > > > On Wed, May 01, 2024 at 06:06:51PM +0100, Russell King (Oracle) wrote: > > > > > > Between 5.4 and 5.15, the guests view of HPDS, CnP, XNX and AC2 > > > > > > changed their value on the same Neoverse N1 r3p1 hardware which makes > > > > > > migrating between these kernels on the host problematical. > > > > > > > > > > It'd be helpful to expand a bit more on how these fields changed, better > > > > > yet if we can blame it back to a commit. I'm guessing the only direction > > > > > of migration you care about is old -> new then? > > > > > > > > Yes. For MMFR4_EL1, we see 0 with our 5.4 based kernel, and 0x21110 > > > > with our 5.15 kernel. I've been looking at tracking down which commit > > > > is responsible but I've come up with nothing that fits. > > > > > > > > The only change I can see is the FTR definition for MMFR4, but this > > > > always included 4:7 (AC2) which changed 0 -> 1. So... no idea what > > > > commit caused the change. > > > > > > > > There are a load of other registers that we need sorting, but this > > > > is just a test forray into attempting to solve this. > > > > > > Got it, let me see if I can find it then. Do share that list of > > > problematic registers when you have it, hopefully this isn't the tip of > > > the iceberg... > > > > There unfortunately is an iceberg, but hopefully it isn't big enough to > > sink a ship! > > > > Besides ID_MMFR4_EL1, here are the other differences we've identified. > > Note that these are Oracle's UEK kernels, so based on stable kernel > > branches. > > > > Register Field 5.4.x 5.15.x > > ID_PFR0_EL1 CSV2 0 1 > > ID_ISAR6_EL1 DP 0 1 > > ID_PFR2_EL1 SSBS 0 1 > > CSV3 0 1 > > ID_AA64DFR0_EL1 PMSVer 1 0 > > DebugVer 8 6 > > ID_AA64MMFR1_EL1 XNX 0 1 > > ID_AA64MMFR2_EL1 EVT 0 1 > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2 > > 0x12 0 > > I'm finding sys_regs.c very unintuitive for working out what we allow > to be written, because it's all coded in negative-logic. By that I mean > the mask values are all ~(what-we-don't-allow) rather than a positive > this-is-what-we-allow. So I've ended up creating a table, looking up > the registers and working out what's read-only and what's read-write. [...] Using positive or negative logic doesn't really have any impact on the result. It often is a matter of concisely expressing what is allowed or not. There is also the fact that a lot of the KVM code now checks for "feature downgrade" and enforces it. Construct such as: if (!kvm_has_feat(kvm, ID_AA64ISAR0_EL1, TLB, OS)) kvm->arch.fgu[HFGITR_GROUP] |= (HFGITR_EL2_TLBIRVAALE1OS| HFGITR_EL2_TLBIRVALE1OS | HFGITR_EL2_TLBIRVAAE1OS | HFGITR_EL2_TLBIRVAE1OS | HFGITR_EL2_TLBIVAALE1OS | HFGITR_EL2_TLBIVALE1OS | HFGITR_EL2_TLBIVAAE1OS | HFGITR_EL2_TLBIASIDE1OS | HFGITR_EL2_TLBIVAE1OS | HFGITR_EL2_TLBIVMALLE1OS); use negative logic by expressing what we don't want to enable. In the end, consistency matters. 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