From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86405524C4; Mon, 9 Sep 2024 17:50:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725904203; cv=none; b=TzSKoui+2vNNgB1MoWEPL9AEG/eOzWso//wAmU05amlNWRHey1X8wAlc1sJOWqkgmN6CTpgLz/mS0f1/UPbQx71tubi/LGvrAgP/IsJO5SGokK1Ii/CNWI+7Ug9f5A2iyLVwUp8kGGA0xz8XY15Jnk3lqnGSWCr1DH705vcswdA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725904203; c=relaxed/simple; bh=hK/4GbdXpLIULaK6ROtHykQDdJiSdgYZCjHci7MMSts=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=NVOfb4echgNVpyaJnGdKvHq2uCTUx5ZcKALPq8JW6OBoTGUNeC3q2pfpkg41FgMc24Bl37zE46RLXPt8cVyypkNIngaBBXrHgpGuK1/CVH0KNPSNT3MZeAyNoFwYcgmcjabGGVml0W5frn9ZWHNutuffFGSBnxumEpIfqiX8+V0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KVTOkUku; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KVTOkUku" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EED88C4CEC5; Mon, 9 Sep 2024 17:50:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725904203; bh=hK/4GbdXpLIULaK6ROtHykQDdJiSdgYZCjHci7MMSts=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KVTOkUkuN3byRaenEdl6O5ifBUjp/kkwHKW+R8Hv+y1s1C1Y9pquePmrVx/zAbDsT Sjf53s5tYBzU3sbSiw+qf+lrkdBZZZRt07n3nwjmjv0kMmZvGVS8C/9d3DcJy9bkGd kJTgDOV+IqnHnxHDeCTHGAX9fVv0rRInAfInrX1pADPzgV0kuOYpAT2/XXZZCNP/L4 ROmyC/ZOeTAseb3oc0VAz/8wovheumh2fgTRBK+shEmvp0m8ZME8h9C1V3avsL9RCi yMtDb7dh4dOjU1esWN/8O7bW5YxRIU3Qg27MwVVyC0YhaKrK/7Gd9dRC7n3IECJyTD tCQtakJk1CqLg== 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 1sniWW-00BDVX-MN; Mon, 09 Sep 2024 18:50:00 +0100 Date: Mon, 09 Sep 2024 18:50:00 +0100 Message-ID: <8634m890on.wl-maz@kernel.org> From: Marc Zyngier To: Shameerali Kolothum Thodi Cc: Oliver Upton , "kvmarm@lists.linux.dev" , Sebastian Ott , James Morse , Suzuki K Poulose , yuzenghui , "kvm@vger.kernel.org" , Shaoqin Huang , Eric Auger , "Wangzhou (B)" Subject: Re: [PATCH v5 07/10] KVM: arm64: Treat CTR_EL0 as a VM feature ID register In-Reply-To: <8e361ab82d6c4adcb15890cd3cab48ee@huawei.com> References: <20240619174036.483943-1-oliver.upton@linux.dev> <20240619174036.483943-8-oliver.upton@linux.dev> <0db19a081d9e41f08b0043baeef16f16@huawei.com> <864j6o94fz.wl-maz@kernel.org> <8e361ab82d6c4adcb15890cd3cab48ee@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) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: shameerali.kolothum.thodi@huawei.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev, sebott@redhat.com, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, kvm@vger.kernel.org, shahuang@redhat.com, eric.auger@redhat.com, wangzhou1@hisilicon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 09 Sep 2024 18:16:55 +0100, Shameerali Kolothum Thodi wrote: > > > > > -----Original Message----- > > From: Oliver Upton > > Sent: Monday, September 9, 2024 5:57 PM > > To: Marc Zyngier > > Cc: Shameerali Kolothum Thodi ; > > kvmarm@lists.linux.dev; Sebastian Ott ; James Morse > > ; Suzuki K Poulose ; > > yuzenghui ; kvm@vger.kernel.org; Shaoqin Huang > > ; Eric Auger ; Wangzhou > > (B) > > Subject: Re: [PATCH v5 07/10] KVM: arm64: Treat CTR_EL0 as a VM feature ID > > register > > > > On Mon, Sep 09, 2024 at 05:28:48PM +0100, Marc Zyngier wrote: > > > Hi Shameer, > > > > > > On Mon, 09 Sep 2024 16:19:54 +0100, > > > Shameerali Kolothum Thodi > > wrote: > > > > > > > > Hi Oliver/Sebastian, > > > > > > > > > -----Original Message----- > > > > > From: Oliver Upton > > > > > Sent: Wednesday, June 19, 2024 6:41 PM > > > > > To: kvmarm@lists.linux.dev > > > > > Cc: Marc Zyngier ; James Morse > > > > > ; Suzuki K Poulose > > ; > > > > > yuzenghui ; kvm@vger.kernel.org; Sebastian > > > > > Ott ; Shaoqin Huang ; > > Eric > > > > > Auger ; Oliver Upton > > > > > > > > > > Subject: [PATCH v5 07/10] KVM: arm64: Treat CTR_EL0 as a VM > > > > > feature ID register > > > > > > > > [...] > > > > > > > > > @@ -2487,7 +2490,10 @@ static const struct sys_reg_desc > > > > > sys_reg_descs[] = { > > > > > { SYS_DESC(SYS_CCSIDR2_EL1), undef_access }, > > > > > { SYS_DESC(SYS_SMIDR_EL1), undef_access }, > > > > > { SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, > > > > > CSSELR_EL1 }, > > > > > - { SYS_DESC(SYS_CTR_EL0), access_ctr }, > > > > > + ID_WRITABLE(CTR_EL0, CTR_EL0_DIC_MASK | > > > > > + CTR_EL0_IDC_MASK | > > > > > + CTR_EL0_DminLine_MASK | > > > > > + CTR_EL0_IminLine_MASK), > > > > > > > > (Sorry if this was discussed earlier, but I couldn't locate it > > > > anywhere.) > > > > > > > > Is there a reason why we can't make the L1Ip writable as well here? > > > > We do have hardware that reports VIPT and PIPT for L11p. > > > > > > > > The comment here states, > > > > https://elixir.bootlin.com/linux/v6.11-rc7/source/arch/arm64/kernel/ > > > > cpufeature.c#L489 > > > > > > > > " If we have differing I-cache policies, report it as the weakest - VIPT." > > > > > > > > Does this also mean it is safe to downgrade the PIPT to VIPT for Guest as > > well? > > > > > > It should be safe, as a PIPT CMO always does at least the same as > > > VIPT, and potentially more if there is aliasing. > > > > +1, there was no particular reason why this wasn't handled before. > > > > We should be careful to only allow userspace to select VIPT or PIPT (where > > permissible), and not necessarily any value lower than what's reported by > > hardware. > > VIPT 0b10 > PIPT 0b11 > > Ok. Just to clarify that " not necessarily any value lower than what's reported by > hardware" means userspace can set PIPT if hardware supports VIPT? No, exactly the opposite. If the HW advertises VIPT, we can set anything else. If the HW advertises PIPT, we can lie to the guest and set VIPT. And if the HW advertises any of the two reserved values, it can but in hell... ;-) > Based on this, > " If we have differing I-cache policies, report it as the weakest - VIPT." , I was thinking > the other way around(see "safe to downgrade PIPT to VIPT"). But Marc also > seems to suggest PIPT CMO ends up doing atleast same as VIPT and more, so it looks like > the other way. If that's the case, what does that "report it as the weakest" means for host? "report it as the weakest" means that if you have a machine with two sets of CPUs, one implementing PIPT and the other VIPT, you report the crappiest of the two because SW cannot know which CPU it is running on. With that, SW running with VIPT on PIPT will do a bit extra work, but will still work fine. M. -- Without deviation from the norm, progress is not possible.