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 4EDA1C3064D for ; Fri, 28 Jun 2024 08:11:08 +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:MIME-Version: Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Message-ID:Date :Subject:CC:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zyf0kEWu9c49A2wHRAqJclkHEjIr05jwYzmY2h9mK7Q=; b=dwHtU3AzU2+tDZD5umQ/OP3gYk td2y2q/+Yutz8LDvv+iWeb0lI9gh66KPUqqAzgUaC8CC7i8Pe5xXZF0bEDJq3dpP1BU2SRm51fwNs lJtwjx1XR3P00OCEE4+nZlygKlK1MqhDE5cklREG7b1IN/XECZcizuSUqIvb1+4uy9fkkwsPFLdxv o8uH5AalDx3pnTjfflhfAxo8FFvGwtP7WgF31tD4hDtWxV1Eotq9PnNuoL9BOvZGjb03Jcek7gtyN TLuoE2VJNggNyl3wvE2/0umb/RShrjvmOL+0tFiXuUOM1uCx5DbUFOjLZT6P+T+9ppxOOqmFLQoJj 1597tExw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sN6h5-0000000D1TZ-0DRK; Fri, 28 Jun 2024 08:10:55 +0000 Received: from szxga02-in.huawei.com ([45.249.212.188]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sN6gv-0000000D1QJ-3Dfx for linux-arm-kernel@lists.infradead.org; Fri, 28 Jun 2024 08:10:47 +0000 Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4W9Skg4fR8zdfPf; Fri, 28 Jun 2024 16:08:59 +0800 (CST) Received: from kwepemd500012.china.huawei.com (unknown [7.221.188.25]) by mail.maildlp.com (Postfix) with ESMTPS id 6860218009B; Fri, 28 Jun 2024 16:10:34 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (7.191.163.240) by kwepemd500012.china.huawei.com (7.221.188.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.34; Fri, 28 Jun 2024 16:10:33 +0800 Received: from lhrpeml500005.china.huawei.com ([7.191.163.240]) by lhrpeml500005.china.huawei.com ([7.191.163.240]) with mapi id 15.01.2507.039; Fri, 28 Jun 2024 09:10:31 +0100 From: Shameerali Kolothum Thodi To: James Morse , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" CC: Marc Zyngier , Oliver Upton , Suzuki K Poulose , yuzenghui , Catalin Marinas , Will Deacon , Jing Zhang , "Wangzhou (B)" Subject: RE: [PATCH v3 4/6] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes Thread-Topic: [PATCH v3 4/6] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes Thread-Index: AQHae7EcWBfUhFLWfESLuHqxbBJIrbHdahYA Date: Fri, 28 Jun 2024 08:10:31 +0000 Message-ID: References: <20240321165728.31907-1-james.morse@arm.com> <20240321165728.31907-5-james.morse@arm.com> In-Reply-To: <20240321165728.31907-5-james.morse@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.177.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240628_011046_181304_C9EB3245 X-CRM114-Status: GOOD ( 27.23 ) 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 Hi James, > -----Original Message----- > From: linux-arm-kernel On > Behalf Of James Morse > Sent: Thursday, March 21, 2024 4:57 PM > To: linux-arm-kernel@lists.infradead.org; kvmarm@lists.linux.dev > Cc: Marc Zyngier ; Oliver Upton ; > Suzuki K Poulose ; yuzenghui > ; Catalin Marinas ; Will > Deacon ; Jing Zhang ; James > Morse > Subject: [PATCH v3 4/6] KVM: arm64: Disable MPAM visibility by default an= d > ignore VMM writes >=20 > commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits in > ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests, > but didn't add trap handling. A previous patch supplied the missing trap > handling. >=20 > Existing VMs that have the MPAM field of ID_AA64PFR0_EL1 set need to > be migratable, but there is little point enabling the MPAM CPU > interface on new VMs until there is something a guest can do with it. >=20 > Clear the MPAM field from the guest's ID_AA64PFR0_EL1 and on hardware > that supports MPAM, politely ignore the VMMs attempts to set this bit. >=20 > Guests expossed to this bug have the sanitised value of the MPAM field, > so only the correct value needs to be ignored. This means the field > can continue to be used to block migration to incompatible hardware > (between MPAM=3D1 and MPAM=3D5), and the VMM can't rely on the field > being ignored. >=20 > Signed-off-by: James Morse > --- > arch/arm64/kvm/sys_regs.c | 32 +++++++++++++++++++++++++++++++- > 1 file changed, 31 insertions(+), 1 deletion(-) >=20 > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index d6afb21849de..56d70a90c965 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1685,6 +1685,13 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct > kvm_vcpu *vcpu, >=20 > val &=3D ~ID_AA64PFR0_EL1_AMU_MASK; >=20 > + /* > + * MPAM is disabled by default as KVM also needs a set of PARTID to > + * program the MPAMVPMx_EL2 PARTID remapping registers with. But > some > + * older kernels let the guest see the ID bit. > + */ > + val &=3D ~ID_AA64PFR0_EL1_MPAM_MASK; > + > return val; > } >=20 > @@ -1795,6 +1802,29 @@ static int set_id_dfr0_el1(struct kvm_vcpu *vcpu, > return set_id_reg(vcpu, rd, val); > } >=20 > +static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu, > + const struct sys_reg_desc *rd, u64 user_val) > +{ > + u64 hw_val =3D read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1); > + u64 mpam_mask =3D ID_AA64PFR0_EL1_MPAM_MASK; > + > + /* > + * Commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature > bits > + * in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 > to > + * guests, but didn't add trap handling. KVM doesn't support MPAM and > + * always returns an UNDEF for these registers. The guest must see 0 > + * for this field. > + * > + * But KVM must also accept values from user-space that were provided > + * by KVM. On CPUs that support MPAM, permit user-space to write > + * the santisied value to ID_AA64PFR0_EL1.MPAM, but ignore this field. > + */ > + if ((hw_val & mpam_mask) =3D=3D (user_val & mpam_mask)) > + user_val &=3D ~ID_AA64PFR0_EL1_MPAM_MASK; > + > + return set_id_reg(vcpu, rd, user_val); > +} Commit 14e270fa5c4c(arm64/cpufeature: Add remaining feature bits in ID_AA64= PFR1 register") exposes the MPAMFRAC filed in in AA64PFR1_EL1. Don't we need a similar hand= ling for that=20 as well to handle the FEAT_MPAMv0p1 case?=20 Also any chance you plan to respin this series soon? We do have hardware th= at benefits from this series. Thanks, Shameer