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 446E4CA5FC1 for ; Sat, 3 Oct 2026 12:30:20 +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=+JZDKY8Pm+m7xlMt9GpnBgo5K7r0EZ5kqFaq0xkbApQ=; b=a87w+4TTXCXh2+2E1xlLToD8NJ AGYRLg7f3MbDYfeXwgbiSRGqHPnxudKV85bpDRGZmHaE0o8dVFYfqDn+lkLg2ypB1qsXP6N/oDO79 DBauP02HVfFNtTx8i/BSFCO+DrtRumeh5x6P+HTLKNeTkJQvpF+Vpob7HqMPSH8a2P4nhDJg2Dkuh AahwHeazkMSvSNA2oK3kmFJ9LC19pHgFLRQxLi+f/5r9T2KNkgDrGoxx6449TaRtXeb8KZ2dj2GpY fi2QJEYb5TcWNEf3100q1/dA+f7faYTHwFxXVpTcZCL3NrCDmHEDRWyPV64+IL9nSB+lGoB9JffpM X6hq+DUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xCysU-0000000DUiG-3JFs; Sat, 03 Oct 2026 12:30:10 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xCysS-0000000DUhz-2TMl for linux-arm-kernel@lists.infradead.org; Sat, 03 Oct 2026 12:30:08 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 3B16243CFE; Sat, 3 Oct 2026 12:30:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 128AE1F0089B; Sat, 3 Oct 2026 12:30:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791030608; bh=+JZDKY8Pm+m7xlMt9GpnBgo5K7r0EZ5kqFaq0xkbApQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=h9P3fNIuaXDWPgnrzBJXr3TwwCnJIpQSYNxZlXeEHm2JqzisfBbyrtL3CknxAKyGL pFR27cXnjweG14YpvqvCpRtFBN4DmIFcOnWoqI64jOzE/cWeEHvGmTT8gNsPOjFCNN /zz6FOMCU0mAoCdVD9zMQWiDme42glgKUbek61IZiAY5Nx8nNvk+lnx6lDiEHqW7Py OvgFOYIRsaujI9O70Qp4KgCgDHhOLaEHEaifYQC1hCdwnqzHMaRAPgeJnBIDwJ8OKw sElI/OlfeRFtEa/grB5n792AP6fsopfDlAurP6TrxyrzXHOqufQdZmqfHJjXo4OOtR s6TngiAD94apA== 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.98.2) (envelope-from ) id 1xCysP-0000000GWsH-3y6y; Sat, 03 Oct 2026 12:30:06 +0000 Date: Sat, 03 Oct 2026 13:30:05 +0100 Message-ID: <86fqyn2che.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Joey Gouly , Suzuki K Poulose , Shuah Khan , Oliver Upton , Fuad Tabba , Peter Maydell , Leonardo Bras , Wei-Lin Chang , Yao Yuan , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v21 02/15] KVM: arm64: Refuse to start a guest with S1PIE or S1POE but not TCR2 In-Reply-To: <20260930-arm64-gcs-v21-2-3556644cd927@kernel.org> References: <20260930-arm64-gcs-v21-0-3556644cd927@kernel.org> <20260930-arm64-gcs-v21-2-3556644cd927@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/30.1 (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, catalin.marinas@arm.com, will@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, shuah@kernel.org, oupton@kernel.org, fuad.tabba@linux.dev, peter.maydell@linaro.org, leo.bras@arm.com, weilin.chang@arm.com, yaoyuan@linux.alibaba.com, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, 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-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 Wed, 30 Sep 2026 22:48:12 +0100, Mark Brown wrote: > > Since there is an architectural dependency between the features as an > optimisation we only context switch guest registers for FEAT_S1PIE and > FEAT_S1POE if the guest also has FEAT_TCR2. We do not, however, enforce > this as a requirement when starting a guest and only configure the traps > for accessing the registers based on their individual features. This means > that a VMM can configure a guest which can read and write the system > registers for FEAT_S1PIE and FEAT_S1POE without the hypervisor updating the > values of these registers for the guest. > > Avoid this by refusing to create a guest with an affected configuration. > > Rather than doing something data driven we open code the checks, I started > doing something data driven but it was very clear that such code should be > shared with the host kernel cpufeature code. Refactoring for that seemed > like disproportionate effort and invasiveness for the context so is > deferred for followup work. This *absolutely* needs to be data driven, and we're not going back to over two years ago. We already have most of what is needed in config.c, and it is only a matter of making sure that S1PxE is only enabled for the guest if TCR2 and ATS1A are also present. If that means additional sanitisation of the idregs when finalised, so be it. If userspace decides to expose crap in the ID registers, that's its own problem, and we're not in the business of enforcing idiotic configurations. The only thing that matters is that the state that KVM deals with is consistent. M. -- Without deviation from the norm, progress is not possible.