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 1E0F3C433F5 for ; Tue, 26 Apr 2022 09:16:57 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=v5ejOyIvhW4u3zW/dIqAut86pglJk7mSUNPHEKU3G+I=; b=SAYY7OXFMBhSj8 ai2EbfJJ692e62Ylnqz9JdzRzyEG/vp61+YMfkOi8oYW2NN5qy25taUPSURQzw56qgAp15kLs2DeZ jF+DhZDsVd5NSO2dbuKEoSxEdLw+9wqtNVKPPt5C490fnhwDCN2qD/nG8y7Od8zPtR6mLwWvujWCQ VBn7mo0iIDvCypd0kM1ILUuieEp4UKDu6V/GRc6doG3jm1WYwzgCMdJKS0xbaL+tMgX+TBEG1hN2J je1NH5Hx2MnH4yOMqrY4lvbWLlnbbdOQnGHTHgwUZGVg6dSmoR0ed6uy8uLppUwtUTkDOugPqUlRU jEFoOyYBa0lRKLfeJnPg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njHIX-00DZ35-Rx; Tue, 26 Apr 2022 09:15:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njHIU-00DZ2P-6u for linux-arm-kernel@lists.infradead.org; Tue, 26 Apr 2022 09:15:52 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 854F823A; Tue, 26 Apr 2022 02:15:48 -0700 (PDT) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D32D23F73B; Tue, 26 Apr 2022 02:15:46 -0700 (PDT) Date: Tue, 26 Apr 2022 10:15:43 +0100 From: Alexandru Elisei To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, reijiw@google.com, ricarkol@google.com Subject: Re: [PATCH v3 0/5] KVM: arm64: Limit feature register reads from AArch32 Message-ID: References: <20220425235342.3210912-1-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220425235342.3210912-1-oupton@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220426_021550_381646_294A222E X-CRM114-Status: GOOD ( 25.83 ) 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 Hi, On Mon, Apr 25, 2022 at 11:53:37PM +0000, Oliver Upton wrote: > KVM/arm64 does not restrict the guest's view of the AArch32 feature > registers when read from AArch32. HCR_EL2.TID3 is cleared for AArch32 > guests, meaning that register reads come straight from hardware. This is > problematic as KVM relies on read_sanitised_ftr_reg() to expose a set of > features consistent for a particular system. > > Appropriate handlers must first be put in place for CP10 and CP15 ID > register accesses before setting TID3. Rather than exhaustively > enumerating each of the encodings for CP10 and CP15 registers, take the > lazy route and aim the register accesses at the AArch64 system register > table. > > Patches 1-2 are small cleanups to how we handle register emulation > failure. No functional change for current KVM, but required to do > register emulation correctly in this series. > > Patch 3 reroutes the CP15 registers into the AArch64 table, taking care > to immediately RAZ undefined ranges of registers. This is done to avoid > possibly conflicting with encodings for future AArch64 registers. > > Patch 4 installs an exit handler for the CP10 ID registers and also > relies on the general AArch64 register handler to implement reads. > > Finally, patch 5 actually sets TID3 for AArch32 guests, providing > known-safe values for feature register accesses. > > There is an argument that the series is in fact a bug fix for running > AArch32 VMs on heterogeneous systems. To that end, it could be > blamed/backported to when we first knew better: > > 93390c0a1b20 ("arm64: KVM: Hide unsupported AArch64 CPU features from guests") > > But I left that tag off as in the aforementioned change skipping > AArch32 was intentional. Up to you, Marc, if you want to call it a > bugfix ;-) > > Applies cleanly to 5.18-rc4. > > Tested with AArch32 kvm-unit-tests and booting an AArch32 debian guest > on a Raspberry Pi 4. Additionally, I tested AArch32 kvm-unit-tests w/ > pmu={on,off} and saw no splat, as Alex had discovered [1]. The test > correctly skips with the PMU feature bit disabled now. But a guest who ignores the fact that the ID register doesn't advertise a PMU and tries to access the PMU registers regardless would still trigger the splat, right? I don't think the series changes the AArch32 PMU registers visibility to REG_HIDDEN when the VCPU feature is not set. Thanks, Alex > > [1]: https://lore.kernel.org/r/20220425145530.723858-1-alexandru.elisei@arm.com > > v1: https://lore.kernel.org/kvmarm/20220329011301.1166265-1-oupton@google.com/ > v2: https://lore.kernel.org/r/20220401010832.3425787-1-oupton@google.com > > v2 -> v3: > - Collect R-b from Reiji (thanks!) > - Adopt Marc's suggestion for CP15 register handling > - Avoid writing to Rt when emulation fails (Marc) > - Print some debug info on an unexpected CP10 register access (Reiji) > > v1 -> v2: > - Actually set TID3! Oops. > - Refactor kvm_emulate_cp15_id_reg() to check preconditions before > proceeding to emulation (Reiji) > - Tighten up comment on kvm_is_cp15_id_reg() to indicate that the only > other trapped ID register (CTR) is already handled in the cp15 > > Oliver Upton (5): > KVM: arm64: Return a bool from emulate_cp() > KVM: arm64: Don't write to Rt unless sys_reg emulation succeeds > KVM: arm64: Wire up CP15 feature registers to their AArch64 > equivalents > KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handler > KVM: arm64: Start trapping ID registers for 32 bit guests > > arch/arm64/include/asm/kvm_arm.h | 3 +- > arch/arm64/include/asm/kvm_emulate.h | 7 - > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/handle_exit.c | 1 + > arch/arm64/kvm/sys_regs.c | 197 +++++++++++++++++++++++---- > arch/arm64/kvm/sys_regs.h | 7 + > 6 files changed, 178 insertions(+), 38 deletions(-) > > -- > 2.36.0.rc2.479.g8af0fa9b8e-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel