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 9202AD2FFEC for ; Fri, 18 Oct 2024 10:41:26 +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-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sui7IuRzpAmATHOmlxBmFkXdLPnpJgEXhqhy4EiZ/us=; b=ZDsVNiNUi1C1LwFXqMfnvaG7RW HDINkJgh0/MS5iCkeVqFKvvWW3HS5FA5ScM4Iqq5qY9vNOSUBEeM+9qZyC1cIhYMWwD5+etjBqP4J RWUwd9y38xp0KQpuOV0etyBD0arxCWqtC6BpjRPEwXwVYUNRKiG4yhLSgogJmHdt0S0UV8PM9/H6e R+pZRr9B0bcaHopk5arz6UPp/UblJ6jQVtpLeCxiVXGJDyRgOJQxiNazwu7PAMNmZ+xChBZed26AH HoMFHg24Aw3kV6WdD4/9V7IVl6adzeBEKIqhIjzYvm5oioU248jZgxor6hnzFeoXNBpkATsFtys4C 1frOYA/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1kPz-00000000OqJ-221I; Fri, 18 Oct 2024 10:41:15 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t1k8j-00000000M2X-46SO for linux-arm-kernel@lists.infradead.org; Fri, 18 Oct 2024 10:23:27 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 2FBADA435B8; Fri, 18 Oct 2024 10:23:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0CEAC4CEC3; Fri, 18 Oct 2024 10:23:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729247004; bh=/66c9/H7Fi/NiRoqzhE7bvDtC0JZ26GedV/t2crh9Hw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WzCsJLhtsMzfPKjje3WJITjpl786xJYBrMLrjuBXAt/daIhP4/Vp4K6igJqRbfVB/ 5lnzqEOLxeJ96J73R6LpLAp/lRI8XUoldrT67apa0XXiRmBHnEiFscsIlogHLxVLbI CBsSJMYISNxPzzdeckl8d7/gxSzx3iin8j5Hfc20DxyzWhv8ZHP/GnlXwOw3ftnyN5 yquzrj/3SFqhrv5SplzpQ2R8rJcL+vWwNsj0RxiwoLRmNZvlEGCMYJHGpbLdn+PM+P OIYg6pBbWhJMqGxBTz+Vny9W0c7IGcbOhVwm2oAFOaK4DJMeNMhs/VnAguInLRE2N3 J2OP96qNpZ4EA== 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 1t1k8g-004kD1-8X; Fri, 18 Oct 2024 11:23:22 +0100 Date: Fri, 18 Oct 2024 11:23:20 +0100 Message-ID: <86h6994smf.wl-maz@kernel.org> From: Marc Zyngier To: Shameer Kolothum Cc: , , , , , , , , Subject: Re: [PATCH] KVM: arm64: Make L1Ip feature in CTR_EL0 writable from userspace In-Reply-To: <20241017085925.40532-1-shameerali.kolothum.thodi@huawei.com> References: <20241017085925.40532-1-shameerali.kolothum.thodi@huawei.com> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: shameerali.kolothum.thodi@huawei.com, kvmarm@lists.linux.dev, oliver.upton@linux.dev, james.morse@arm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com 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-20241018_032326_162287_2E07480E X-CRM114-Status: GOOD ( 32.97 ) 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, 17 Oct 2024 09:59:25 +0100, Shameer Kolothum wrote: >=20 > Only allow userspace to set VIPT(0b10) or PIPT(0b11) for L1Ip based on > what hardware reports as both=C2=A0AIVIVT (0b01) and VPIPT (0b00) are > documented as reserved. >=20 > Using a VIPT for Guest where hardware reports PIPT may lead to over > invalidation, but is still correct. Hence, we can allow downgrading > PIPT to VIPT, but not the other way around. >=20 > Signed-off-by: Shameer Kolothum > --- > This is based on the dicsussion here[0]. > https://lore.kernel.org/kvmarm/0db19a081d9e41f08b0043baeef16f16@huawei.co= m/ >=20 > Also depends on Joey's series[1] as it make use of the ID_FILTERED macro. >=20 > I am not sure we need to explicitly make the ftr type as FTR_LOWER_SAFE > in kvm_arm64_ftr_safe_value() or as mentioned below can depend on > arm64_ftr_safe_value() for this ftr bits. I think relying on the arch code for this is the right thing to do. This was designed to cope with heterogeneous systems where you could have both PIPT and VIPT caches in the system, and we don't allow a late comer to be VIPT if we're decided on PIPT (hence the FTR_EXACT). >=20 > Please take a look and let me know. >=20 > Thanks, > Shameer >=20 > [0] https://lore.kernel.org/kvmarm/0db19a081d9e41f08b0043baeef16f16@huawe= i.com/ > [1] https://lore.kernel.org/kvmarm/20241015133923.3910916-1-joey.gouly@ar= m.com/ > --- > arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++++++++++++---- > 1 file changed, 28 insertions(+), 4 deletions(-) >=20 > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index d97ccf1c1558..819dcb63febd 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1872,6 +1872,28 @@ static int set_id_aa64pfr1_el1(struct kvm_vcpu *vc= pu, > return set_id_reg(vcpu, rd, user_val); > } > =20 > +static int set_ctr_el0(struct kvm_vcpu *vcpu, > + const struct sys_reg_desc *rd, u64 user_val) > +{ > + u8 user_L1Ip =3D SYS_FIELD_GET(CTR_EL0, L1Ip, user_val); > + > + /* > + * Both AIVIVT (0b01) and VPIPT (0b00) are documented as reserved. > + * Hence only allow to set VIPT(0b10) or PIPT(0b11) for L1Ip based > + * on what hardware reports. > + * > + * Using a VIPT software model on PIPT will lead to over invalidation, > + * but still correct. Hence, we can allow downgrading PIPT to VIPT, > + * but not the other way around. This is handled via arm64_ftr_safe_val= ue() > + * as CTR_EL0 ftr_bits has L1Ip field type FTR_EXACT with safe value > + * set as VIPT) > + */ > + if (user_L1Ip < CTR_EL0_L1Ip_VIPT) > + return -EINVAL; I'm not overly fond of this, because the ordering of cache types is arbitrary (it really is an enumeration). I would rather see the allowed cache types explicitly listed. It doesn't change a thing, but makes it all much more readable. With this fixed: Reviewed-by: Marc Zyngier Thanks, M. --=20 Without deviation from the norm, progress is not possible.