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 D7C78C3DA4A for ; Thu, 22 Aug 2024 17:49: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:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TwyKdP3lcLr0qsPprb0/HSzlxAEUGa44mLRDydBA4s0=; b=3+Xg1YZnmb1bRMwQvH1ZU1F0If g8De52Dtc9gaPrs62kgzewMyRegmFAnjCQSW3rA4Lq7NKcznICpqfMogIO38xVdXfv+vJ5SuttRsF h18ykkrCUlY2OpgBNyBEKBwkaeh5mdPWAFfs1rKBUdTIgpS1fVtsdqIwtZTn0MBEaCOq31ZNTatJA qPkmg+SEgItQW9CRyouBD3XY06j4SUm/ff0b7/al8SUbYOmZk4uU2hWLymYoi4AEZRtInJBrT+r+K YYTkeXp14eOdG8R5pPj0ygq2a26wL5q9zSLv2WMg5JGLPeBTNSYm0pyOCA1l8AyLkgvNu08f5/cZ3 wN/ysbSw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1shBvz-0000000DrBh-0kmF; Thu, 22 Aug 2024 17:49:19 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1shBr4-0000000DpnS-1Ohc for linux-arm-kernel@lists.infradead.org; Thu, 22 Aug 2024 17:44:16 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 1E0A7CE0FF7; Thu, 22 Aug 2024 17:44:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A86DC32782; Thu, 22 Aug 2024 17:44:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724348651; bh=cegSBI2AjOyPEuaaHuikZeuINmD27Fy73BpZBPzkNzk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=reLLsGSgLLs9TbINYoQ7LtSZaGtIDLxQS/W9uDxZHFpbsxthQyuvo/ybpUdkqcTcm izWOtRUbKQOcbSvOa0zEdRGk6h8KQrak5UHPyEYUmmpAm7dllRgPVgxZY4hvlhetJz 2Pjk3gMCGXWNyiBD1Q8Xydue9JDyBA2VsqUsaaAXn38SQuOwz7S6AfOs1ERU/CLNic N8mGvsKnRbAZm0jurtQRG/nxjYBZduwrWFaA4ZSv5rIS/FKsoua6ha3W11YLgHVY6n d6UoVhJnvYuXyVH7Bhrm/mgkFa7+5Uxgmi36NoanIT9pdsrq6r5C0YRVLRWdJZTU+R cOrB8Ik/QcFQA== 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 1shBqz-0062ae-4E; Thu, 22 Aug 2024 18:44:09 +0100 Date: Thu, 22 Aug 2024 18:44:08 +0100 Message-ID: <861q2gxxjr.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Oliver Upton , James Morse , Suzuki K Poulose , Catalin Marinas , Will Deacon , Joey Gouly , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] KVM: arm64: Control visibility of S1PIE related sysregs to userspace In-Reply-To: References: <20240821-kvm-arm64-hide-pie-regs-v1-0-08cb3c79cb57@kernel.org> <86ed6ixa32.wl-maz@kernel.org> <86cym2x7cv.wl-maz@kernel.org> <5304749b-04c8-44f4-b4de-b2d0cef61169@sirena.org.uk> <86bk1lygm1.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/29.4 (aarch64-unknown-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: broonie@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, joey.gouly@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org 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-20240822_104414_743226_18A8614A X-CRM114-Status: GOOD ( 32.63 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 22 Aug 2024 16:30:42 +0100, Mark Brown wrote: > > [1 ] > On Wed, Aug 21, 2024 at 05:40:06PM +0100, Marc Zyngier wrote: > > Mark Brown wrote: > > > > Indeed, I was wondering about just adding a description of the relevant > > > ID register field to the sys_regs table. > > > You'd need more than that. > > > How would you express the visibility of TCR2_EL2? It depends on both > > ID_AA64PFR0_EL1.EL2==1 *and* ID_AA64MMFR3_EL1.TCRX==1. So it cannot be > > just a single tuple { idreg, field, value }. It needs to be an > > arbitrary conjunction of those. > > I haven't done an audit for fun cases to see how viable things are, for > the EL2 cases I'd just have an encoding based check for EL2 rather than > explicitly enumerating the ID register for each EL2. That seemed > quicker and less error prone. Sure, you can do that. Or rather, you can do that *right now*. But that's not what the architecture says (there is no statement saying that Op1==4 for an EL2 register). So the forward-looking way to do it is to match the full encoding of a register against the properties that define its existence. Anything else is a short lived hack, and I don't care much for them. But a simple way to deal with that is to encode a property that checks a vcpu creation property (EL2, PAuth...). > > The other cases I'm aware of are more along the lines of features > restricting the values other features/idregs can have (eg, for SME the > information in ID_AA64PFR1_EL1.SME can also be gleaned from > ID_AA64SMFR0_EL1.SMEver). Well, they don't quite advertise the same thing. If you decode the feature specification, you get: (FEAT_SME <-> (AArch64 ID_AA64PFR1_EL1.SME >= 1)) (FEAT_SME2 --> (AArch64 ID_AA64SMFR0_EL1.SMEver >= 1)) (FEAT_SME2 --> (AArch64 ID_AA64PFR1_EL1.SME >= 2)) (((AArch64 ID_AA64SMFR0_EL1.SMEver >= 1) || (AArch64 ID_AA64PFR1_EL1.SME >= 2)) --> FEAT_SME2) (FEAT_SME2p1 <-> (AArch64 ID_AA64SMFR0_EL1.SMEver >= 2)) So SME isn't really advertised in SMEver, SME2 is advertised in both (and it is enough that one advertises SME2 for the feature to be present), and SME2p1 is only advertised in SMEver. That's what we need to implement. Yes, this part of the architecture is... interesting. > For those I'm not sure if visibility checks > are the best approach, if we should audit the registers when starting > the guest to make sure they're self consistent or if we should just pick > the most directly relevant register and rely on userspace to enforce > consistancy. We definitely rely on userspace to enforce consistency. If userspace messes up, it's "garbage in, garbage out". We enforce the sysregs visible by the guest and userspace based on that, and if that means evaluating 10 registers because there is a terrible set of combinations (such as PAuth-like features), so be it. We can always find ways to accelerate that. M. -- Without deviation from the norm, progress is not possible.