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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA003C433FE for ; Thu, 31 Mar 2022 15:34:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5D38040797; Thu, 31 Mar 2022 11:34:19 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYLdDx28lfve; Thu, 31 Mar 2022 11:34:16 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D348640C31; Thu, 31 Mar 2022 11:34:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 687E34087B for ; Thu, 31 Mar 2022 11:34:15 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtpeAtRM99cx for ; Thu, 31 Mar 2022 11:34:10 -0400 (EDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 0C5BE40797 for ; Thu, 31 Mar 2022 11:34:09 -0400 (EDT) Received: by mail-io1-f52.google.com with SMTP id q11so29001743iod.6 for ; Thu, 31 Mar 2022 08:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=R6qVglK0FzawAXT0u5ibNFLRdw4AR1UKBBbJVmhDGmw=; b=f12ZZUEl0m4XNN/vangV6Vr6v1IK2xC1y0f78ppu9bR4Qtu/4hbU7bfXFE6KbOoArQ +Mm0CuHBUdpXPTNte/WciKsKtHgb6w+Hj+7531DSKyEuvGGCRxUa+JKZv8FYwExwaG5X 9ZPcXpqz9u1Y1KlPXSrsSFFR/YsngCCQzH9SC6PtB/ojuebV9c6LWk7VuM8qGbezBpM4 XTv24iderEEW7syCge5Ihsvd+7Yr7pW2qpVV012o84iZ2D70X9Z6Wo/AyI5l13sOBDjP U0e0CqEyG8AO+aIRBSEyHHBdDO56V5rtfM9k+VWIAw0Bz+a3GBH18zLypYweYyUrXnrM Tq2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=R6qVglK0FzawAXT0u5ibNFLRdw4AR1UKBBbJVmhDGmw=; b=YUHLM2gCqxQQO/FgaBQ+/AWv5JGWLcZJvgXIMzVPcpJrstSVxQolN2fYjpRRnjTRlD qtJCQIV1bL4AXu3Ggug5TnKesuAecdOO5GuxumWVD2JVAl85479szqF5T5s0KGuKWo/w whLErISK/dnE3QEISnmPlmSYu8UYQbRTP7gYAlpGrSvkTwI7uPL2Ja9fJpLE30jrYNaU TcojmcQt9rAhg46MraS1ptxn9QpQiZxpHaikbk9BzdvZ7e1dDwf6rweJXcPMCS3XkF+O ZeuAOTgp7WX3N0lhdYdTZAM2g4b+udT06Xk+qDAmt9p6nE+/uF21Cp4jPWTkGRIIADlW wN2g== X-Gm-Message-State: AOAM531LERLhCRLpTLQKB8JUHuuuYI36v5oBEanOBbD13pK+oK7zK8kN IzIOzL6BTeiEXydlodD/q64VnQ== X-Google-Smtp-Source: ABdhPJyDekBrm8Mb4uDZ8bLm4Yo7RYoSABckPoxXi5s6USil5NnmuontTT10XVUc64Tr+EazrPyeFA== X-Received: by 2002:a02:aa0b:0:b0:317:c63a:6625 with SMTP id r11-20020a02aa0b000000b00317c63a6625mr3224223jam.222.1648740848931; Thu, 31 Mar 2022 08:34:08 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id j9-20020a926e09000000b002c9f3388cd4sm1732964ilc.21.2022.03.31.08.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 08:34:08 -0700 (PDT) Date: Thu, 31 Mar 2022 15:34:04 +0000 From: Oliver Upton To: Reiji Watanabe Subject: Re: [PATCH 1/3] KVM: arm64: Wire up CP15 feature registers to their AArch64 equivalents Message-ID: References: <20220329011301.1166265-1-oupton@google.com> <20220329011301.1166265-2-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , kvmarm@lists.cs.columbia.edu, Linux ARM X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Reiji, On Wed, Mar 30, 2022 at 10:45:35PM -0700, Reiji Watanabe wrote: > Hi Oliver, > > On Mon, Mar 28, 2022 at 6:13 PM Oliver Upton wrote: > > > > KVM currently does not trap ID register accesses from an AArch32 EL1. > > This is painful for a couple of reasons. Certain unimplemented features > > are visible to AArch32 EL1, as we limit PMU to version 3 and the debug > > architecture to v8.0. Additionally, we attempt to paper over > > heterogeneous systems by using register values that are safe > > system-wide. All this hard work is completely sidestepped because KVM > > does not set TID3 for AArch32 guests. > > > > Fix up handling of CP15 feature registers by simply rerouting to their > > AArch64 aliases. Punt setting HCR_EL2.TID3 to a later change, as we need > > to fix up the oddball CP10 feature registers still. > > > > Signed-off-by: Oliver Upton > > --- > > arch/arm64/kvm/sys_regs.c | 66 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 66 insertions(+) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index dd34b5ab51d4..30771f950027 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -2339,6 +2339,65 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu, > > return 1; > > } > > > > +static int emulate_sys_reg(struct kvm_vcpu *vcpu, struct sys_reg_params *params); > > + > > +/** > > + * kvm_emulate_cp15_id_reg() - Handles an MRC trap on a guest CP15 access where > > + * CRn=0, which corresponds to the AArch32 feature > > + * registers. > > + * @vcpu: the vCPU pointer > > + * @params: the system register access parameters. > > + * > > + * Our cp15 system register tables do not enumerate the AArch32 feature > > + * registers. Conveniently, our AArch64 table does, and the AArch32 system > > + * register encoding can be trivially remapped into the AArch64 for the feature > > + * registers: Append op0=3, leaving op1, CRn, CRm, and op2 the same. > > + * > > + * According to DDI0487G.b G7.3.1, paragraph "Behavior of VMSAv8-32 32-bit > > + * System registers with (coproc=0b1111, CRn==c0)", read accesses from this > > + * range are either UNKNOWN or RES0. Rerouting remains architectural as we > > + * treat undefined registers in this range as RAZ. > > + */ > > +static int kvm_emulate_cp15_id_reg(struct kvm_vcpu *vcpu, > > + struct sys_reg_params *params) > > +{ > > + int Rt = kvm_vcpu_sys_get_rt(vcpu); > > + int ret = 1; > > + > > + params->Op0 = 3; > > Nit: Shouldn't we restore the original Op0 after emulate_sys_reg() ? > (unhandled_cp_access() prints Op0. Restoring the original one > would be more robust against future changes) > > > + > > + /* > > + * All registers where CRm > 3 are known to be UNKNOWN/RAZ from AArch32. > > + * Avoid conflicting with future expansion of AArch64 feature registers > > + * and simply treat them as RAZ here. > > + */ > > + if (params->CRm > 3) > > + params->regval = 0; > > + else > > + ret = emulate_sys_reg(vcpu, params); > > + > > + /* Treat impossible writes to RO registers as UNDEFINED */ > > + if (params->is_write) > > This checking can be done even before calling emulate_sys_reg(). > BTW, __access_id_reg() also injects UNDEFINED when p->is_write is true. > > > + unhandled_cp_access(vcpu, params); > > + else > > + vcpu_set_reg(vcpu, Rt, params->regval); > > + > > + return ret; > > +} > > + > > +/** > > + * kvm_is_cp15_id_reg() - Returns true if the specified CP15 register is an > > + * AArch32 ID register. > > + * @params: the system register access parameters > > + * > > + * Note that CP15 ID registers where CRm=0 are excluded from this check, as they > > + * are already correctly handled in the CP15 register table. > > I don't think this is true for all of the registers:) > I think at least some of them are not trapped (TCMTR, TLBTR, > REVIDR, etc), and I don't think they are handled in the CP15 > register table. Thanks for the review! This patch was a bit sloppy and indeed skipped a few steps in the comments. I believe the only register in CRm=0 that is trapped is actually CTR, hence the others are not present in the table. I'll send out a v2 soon that addresses your feedback and the other embarrasing omissions on my end :) -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 9E913C433EF for ; Thu, 31 Mar 2022 15:35:33 +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=qrOG+erFywcUKDiuwAAUv+t6PyV+7gSwn1iIOTtWDJk=; b=FsWIlfnHcIlO97 UELFg8/eQjYJVAE2OpHppF9Eu60yuiXS8OG63b+GQjD1UvaJkRwezz6jnv6sUbD4CY+v24NEBmuIr +XGn0LJ3VDxho631U34YjvAgC36bSkkJIGAUzHzPuEAaO/F2sM64sFyFGmx+bTaDQ1wRgqzmOCYQl UN998WhpYq1uaS3XwbsPJBcOrpUTFm0YxIsf92EteZjW7xEueqyHYCBpe2Vk4Fkq9iPvikoSvqTYJ JrOqa5gANY4+egaMnXwe/fRbMfEODJ4Ezk3X/ZAph1ysIVZ2oqnGGxiX5X6ctBslE1+ZmPtRZrn07 +lO4E/PbLCB2UmK214cg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZwoU-002kAm-G1; Thu, 31 Mar 2022 15:34:18 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZwoQ-002k7r-Gb for linux-arm-kernel@lists.infradead.org; Thu, 31 Mar 2022 15:34:16 +0000 Received: by mail-io1-xd35.google.com with SMTP id k25so29003125iok.8 for ; Thu, 31 Mar 2022 08:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=R6qVglK0FzawAXT0u5ibNFLRdw4AR1UKBBbJVmhDGmw=; b=f12ZZUEl0m4XNN/vangV6Vr6v1IK2xC1y0f78ppu9bR4Qtu/4hbU7bfXFE6KbOoArQ +Mm0CuHBUdpXPTNte/WciKsKtHgb6w+Hj+7531DSKyEuvGGCRxUa+JKZv8FYwExwaG5X 9ZPcXpqz9u1Y1KlPXSrsSFFR/YsngCCQzH9SC6PtB/ojuebV9c6LWk7VuM8qGbezBpM4 XTv24iderEEW7syCge5Ihsvd+7Yr7pW2qpVV012o84iZ2D70X9Z6Wo/AyI5l13sOBDjP U0e0CqEyG8AO+aIRBSEyHHBdDO56V5rtfM9k+VWIAw0Bz+a3GBH18zLypYweYyUrXnrM Tq2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=R6qVglK0FzawAXT0u5ibNFLRdw4AR1UKBBbJVmhDGmw=; b=YYMhBtU6WQ4l2CG9yGwsqJAZ6ucyvyYK6iGoZODfp1ozFPuTB4fujLgnhPoB8jv3r9 BrlikbdHPK0qfSsHJ4WotPBbLVCuk3B+35pkQXxJusvIEMs83PN5sTBIbUJJ+qDmTtqQ 67X/QjMnIPibvwhAD2UEfvn9O9JS2hDbyCoESUPKYJxLP/v7VUlwpgVcNvfQ+UTJyQB8 46/qGuy3OrK7oWSYLxPQz8H5R0/X9ojpRTfMCZXmsPl2x2YTT5zcUXdpK6d5Y3rxp8Ol cd/oBJjEyMwmKuCpSD8nFhu5tnUDr19UGOqAZat+KNGe//O66zevbCDhXapFiofmrxco v9ng== X-Gm-Message-State: AOAM530zIFtaB+n74B2yCBdpzTFgohLmKoexfoTw1qZJCyPzcIl8cUq0 STq2YRPT99s1YV1E+SHdX3cMZw== X-Google-Smtp-Source: ABdhPJyDekBrm8Mb4uDZ8bLm4Yo7RYoSABckPoxXi5s6USil5NnmuontTT10XVUc64Tr+EazrPyeFA== X-Received: by 2002:a02:aa0b:0:b0:317:c63a:6625 with SMTP id r11-20020a02aa0b000000b00317c63a6625mr3224223jam.222.1648740848931; Thu, 31 Mar 2022 08:34:08 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id j9-20020a926e09000000b002c9f3388cd4sm1732964ilc.21.2022.03.31.08.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 08:34:08 -0700 (PDT) Date: Thu, 31 Mar 2022 15:34:04 +0000 From: Oliver Upton To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller Subject: Re: [PATCH 1/3] KVM: arm64: Wire up CP15 feature registers to their AArch64 equivalents Message-ID: References: <20220329011301.1166265-1-oupton@google.com> <20220329011301.1166265-2-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220331_083414_630507_68D2B541 X-CRM114-Status: GOOD ( 37.07 ) 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 Reiji, On Wed, Mar 30, 2022 at 10:45:35PM -0700, Reiji Watanabe wrote: > Hi Oliver, > > On Mon, Mar 28, 2022 at 6:13 PM Oliver Upton wrote: > > > > KVM currently does not trap ID register accesses from an AArch32 EL1. > > This is painful for a couple of reasons. Certain unimplemented features > > are visible to AArch32 EL1, as we limit PMU to version 3 and the debug > > architecture to v8.0. Additionally, we attempt to paper over > > heterogeneous systems by using register values that are safe > > system-wide. All this hard work is completely sidestepped because KVM > > does not set TID3 for AArch32 guests. > > > > Fix up handling of CP15 feature registers by simply rerouting to their > > AArch64 aliases. Punt setting HCR_EL2.TID3 to a later change, as we need > > to fix up the oddball CP10 feature registers still. > > > > Signed-off-by: Oliver Upton > > --- > > arch/arm64/kvm/sys_regs.c | 66 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 66 insertions(+) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index dd34b5ab51d4..30771f950027 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -2339,6 +2339,65 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu, > > return 1; > > } > > > > +static int emulate_sys_reg(struct kvm_vcpu *vcpu, struct sys_reg_params *params); > > + > > +/** > > + * kvm_emulate_cp15_id_reg() - Handles an MRC trap on a guest CP15 access where > > + * CRn=0, which corresponds to the AArch32 feature > > + * registers. > > + * @vcpu: the vCPU pointer > > + * @params: the system register access parameters. > > + * > > + * Our cp15 system register tables do not enumerate the AArch32 feature > > + * registers. Conveniently, our AArch64 table does, and the AArch32 system > > + * register encoding can be trivially remapped into the AArch64 for the feature > > + * registers: Append op0=3, leaving op1, CRn, CRm, and op2 the same. > > + * > > + * According to DDI0487G.b G7.3.1, paragraph "Behavior of VMSAv8-32 32-bit > > + * System registers with (coproc=0b1111, CRn==c0)", read accesses from this > > + * range are either UNKNOWN or RES0. Rerouting remains architectural as we > > + * treat undefined registers in this range as RAZ. > > + */ > > +static int kvm_emulate_cp15_id_reg(struct kvm_vcpu *vcpu, > > + struct sys_reg_params *params) > > +{ > > + int Rt = kvm_vcpu_sys_get_rt(vcpu); > > + int ret = 1; > > + > > + params->Op0 = 3; > > Nit: Shouldn't we restore the original Op0 after emulate_sys_reg() ? > (unhandled_cp_access() prints Op0. Restoring the original one > would be more robust against future changes) > > > + > > + /* > > + * All registers where CRm > 3 are known to be UNKNOWN/RAZ from AArch32. > > + * Avoid conflicting with future expansion of AArch64 feature registers > > + * and simply treat them as RAZ here. > > + */ > > + if (params->CRm > 3) > > + params->regval = 0; > > + else > > + ret = emulate_sys_reg(vcpu, params); > > + > > + /* Treat impossible writes to RO registers as UNDEFINED */ > > + if (params->is_write) > > This checking can be done even before calling emulate_sys_reg(). > BTW, __access_id_reg() also injects UNDEFINED when p->is_write is true. > > > + unhandled_cp_access(vcpu, params); > > + else > > + vcpu_set_reg(vcpu, Rt, params->regval); > > + > > + return ret; > > +} > > + > > +/** > > + * kvm_is_cp15_id_reg() - Returns true if the specified CP15 register is an > > + * AArch32 ID register. > > + * @params: the system register access parameters > > + * > > + * Note that CP15 ID registers where CRm=0 are excluded from this check, as they > > + * are already correctly handled in the CP15 register table. > > I don't think this is true for all of the registers:) > I think at least some of them are not trapped (TCMTR, TLBTR, > REVIDR, etc), and I don't think they are handled in the CP15 > register table. Thanks for the review! This patch was a bit sloppy and indeed skipped a few steps in the comments. I believe the only register in CRm=0 that is trapped is actually CTR, hence the others are not present in the table. I'll send out a v2 soon that addresses your feedback and the other embarrasing omissions on my end :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 091A9C433FE for ; Thu, 31 Mar 2022 15:39:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239160AbiCaPk7 (ORCPT ); Thu, 31 Mar 2022 11:40:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240262AbiCaPjM (ORCPT ); Thu, 31 Mar 2022 11:39:12 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DF7B1C8867 for ; Thu, 31 Mar 2022 08:34:11 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id x4so29019630iop.7 for ; Thu, 31 Mar 2022 08:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=R6qVglK0FzawAXT0u5ibNFLRdw4AR1UKBBbJVmhDGmw=; b=f12ZZUEl0m4XNN/vangV6Vr6v1IK2xC1y0f78ppu9bR4Qtu/4hbU7bfXFE6KbOoArQ +Mm0CuHBUdpXPTNte/WciKsKtHgb6w+Hj+7531DSKyEuvGGCRxUa+JKZv8FYwExwaG5X 9ZPcXpqz9u1Y1KlPXSrsSFFR/YsngCCQzH9SC6PtB/ojuebV9c6LWk7VuM8qGbezBpM4 XTv24iderEEW7syCge5Ihsvd+7Yr7pW2qpVV012o84iZ2D70X9Z6Wo/AyI5l13sOBDjP U0e0CqEyG8AO+aIRBSEyHHBdDO56V5rtfM9k+VWIAw0Bz+a3GBH18zLypYweYyUrXnrM Tq2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=R6qVglK0FzawAXT0u5ibNFLRdw4AR1UKBBbJVmhDGmw=; b=AF6FsFz2zia0cJH5iFSngacWabuYXIKvVUT62yM2xRjGLHIGPJfrPa7Cq1T6+JPudj rm1H9P9a1GT97oUBhczoZLDEj3nSqvr6cT2dUWibYQuSn1AWm1yh+sU71DJqhiBAt/R8 OWmOy/Qt6UC0lQ+w6IIGPFRwCkPxvTZodmUK2LV6z/0WQYMtKYreuzGnYRlUJNSNmKr2 DrX8B3iYs1HYznzYQUpQmeCrtFggX1V374E+3cKE2ah8zpPMNyoFOG19hpZvjDDkK5OD GKfaC5GctgweTjgIa65xe97OZG1nw4Mc/Ikz/d+z9zytlyzg9ZLDPmG74gp/ovJVLOe2 sbPw== X-Gm-Message-State: AOAM530m706AMgXSz9r2jD4oRMVb+ScNxzP+CWz42YefXDr+fsh4mpyB fP1WeBL+LA435OUksjLpY1a2FA== X-Google-Smtp-Source: ABdhPJyDekBrm8Mb4uDZ8bLm4Yo7RYoSABckPoxXi5s6USil5NnmuontTT10XVUc64Tr+EazrPyeFA== X-Received: by 2002:a02:aa0b:0:b0:317:c63a:6625 with SMTP id r11-20020a02aa0b000000b00317c63a6625mr3224223jam.222.1648740848931; Thu, 31 Mar 2022 08:34:08 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id j9-20020a926e09000000b002c9f3388cd4sm1732964ilc.21.2022.03.31.08.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 08:34:08 -0700 (PDT) Date: Thu, 31 Mar 2022 15:34:04 +0000 From: Oliver Upton To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller Subject: Re: [PATCH 1/3] KVM: arm64: Wire up CP15 feature registers to their AArch64 equivalents Message-ID: References: <20220329011301.1166265-1-oupton@google.com> <20220329011301.1166265-2-oupton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Reiji, On Wed, Mar 30, 2022 at 10:45:35PM -0700, Reiji Watanabe wrote: > Hi Oliver, > > On Mon, Mar 28, 2022 at 6:13 PM Oliver Upton wrote: > > > > KVM currently does not trap ID register accesses from an AArch32 EL1. > > This is painful for a couple of reasons. Certain unimplemented features > > are visible to AArch32 EL1, as we limit PMU to version 3 and the debug > > architecture to v8.0. Additionally, we attempt to paper over > > heterogeneous systems by using register values that are safe > > system-wide. All this hard work is completely sidestepped because KVM > > does not set TID3 for AArch32 guests. > > > > Fix up handling of CP15 feature registers by simply rerouting to their > > AArch64 aliases. Punt setting HCR_EL2.TID3 to a later change, as we need > > to fix up the oddball CP10 feature registers still. > > > > Signed-off-by: Oliver Upton > > --- > > arch/arm64/kvm/sys_regs.c | 66 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 66 insertions(+) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index dd34b5ab51d4..30771f950027 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -2339,6 +2339,65 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu, > > return 1; > > } > > > > +static int emulate_sys_reg(struct kvm_vcpu *vcpu, struct sys_reg_params *params); > > + > > +/** > > + * kvm_emulate_cp15_id_reg() - Handles an MRC trap on a guest CP15 access where > > + * CRn=0, which corresponds to the AArch32 feature > > + * registers. > > + * @vcpu: the vCPU pointer > > + * @params: the system register access parameters. > > + * > > + * Our cp15 system register tables do not enumerate the AArch32 feature > > + * registers. Conveniently, our AArch64 table does, and the AArch32 system > > + * register encoding can be trivially remapped into the AArch64 for the feature > > + * registers: Append op0=3, leaving op1, CRn, CRm, and op2 the same. > > + * > > + * According to DDI0487G.b G7.3.1, paragraph "Behavior of VMSAv8-32 32-bit > > + * System registers with (coproc=0b1111, CRn==c0)", read accesses from this > > + * range are either UNKNOWN or RES0. Rerouting remains architectural as we > > + * treat undefined registers in this range as RAZ. > > + */ > > +static int kvm_emulate_cp15_id_reg(struct kvm_vcpu *vcpu, > > + struct sys_reg_params *params) > > +{ > > + int Rt = kvm_vcpu_sys_get_rt(vcpu); > > + int ret = 1; > > + > > + params->Op0 = 3; > > Nit: Shouldn't we restore the original Op0 after emulate_sys_reg() ? > (unhandled_cp_access() prints Op0. Restoring the original one > would be more robust against future changes) > > > + > > + /* > > + * All registers where CRm > 3 are known to be UNKNOWN/RAZ from AArch32. > > + * Avoid conflicting with future expansion of AArch64 feature registers > > + * and simply treat them as RAZ here. > > + */ > > + if (params->CRm > 3) > > + params->regval = 0; > > + else > > + ret = emulate_sys_reg(vcpu, params); > > + > > + /* Treat impossible writes to RO registers as UNDEFINED */ > > + if (params->is_write) > > This checking can be done even before calling emulate_sys_reg(). > BTW, __access_id_reg() also injects UNDEFINED when p->is_write is true. > > > + unhandled_cp_access(vcpu, params); > > + else > > + vcpu_set_reg(vcpu, Rt, params->regval); > > + > > + return ret; > > +} > > + > > +/** > > + * kvm_is_cp15_id_reg() - Returns true if the specified CP15 register is an > > + * AArch32 ID register. > > + * @params: the system register access parameters > > + * > > + * Note that CP15 ID registers where CRm=0 are excluded from this check, as they > > + * are already correctly handled in the CP15 register table. > > I don't think this is true for all of the registers:) > I think at least some of them are not trapped (TCMTR, TLBTR, > REVIDR, etc), and I don't think they are handled in the CP15 > register table. Thanks for the review! This patch was a bit sloppy and indeed skipped a few steps in the comments. I believe the only register in CRm=0 that is trapped is actually CTR, hence the others are not present in the table. I'll send out a v2 soon that addresses your feedback and the other embarrasing omissions on my end :) -- Thanks, Oliver