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 5F8D8C10F16 for ; Fri, 3 May 2024 17:28:10 +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=WY1td03ZIs8wZF80MOWmGps0P2EIsr5exTJVvavkz4k=; b=cP/cKByzbaK1Ym JF+va8WwowIDKskzG28cGwIa0FZag4Vr5IVKyNAhMKp3fSdtLmdnT2XnKPjSHL/I4CZ5XXlrKDTnu CZh/7Lvf+j28UTesnqJ731N6ceoosR2JJr52IpyIUh8L5Y3Ypj1+fc7N+B31jhs5HNQC6MhjRXqwa JPNCkx4csZYt4BVQ7rf8YG6p7aInSIL98juS8AI+nU9D21nFHsXZTBE1Vu+C+cAX+k/HTLRGV8nhr UQ5xgA0ZwYmTLOR2mjeEuHfCCn/VjwhV/Iauo2M81J7Fh98JVXTefsP4qhtFstJWoQv+Kd6UGdvZN Xwt58irbm+3Hb/0CdnoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2whV-0000000HObC-0FQT; Fri, 03 May 2024 17:28:01 +0000 Received: from out-189.mta0.migadu.com ([2001:41d0:1004:224b::bd]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2whS-0000000HOZ1-0b8D for linux-arm-kernel@lists.infradead.org; Fri, 03 May 2024 17:27:59 +0000 Date: Fri, 3 May 2024 10:27:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1714757272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lkfu3aF+7HSJzFb8vZvf6vy1XzKC3Kd7KishD/IFflc=; b=mHMQO7jYaWPMY18NmrUK8fAqCVXI7qF4CkWacUl9C0Or8849Sy9zAPd3M1EMMYQaI1Y5Wd SeKkHoPnEit66IrkLwSh5a9vSFVOr1k16rIsw93G2F/JFeJ9FQ2A/WDr9XEEMS+gaIUfw1 dXM/tFBCitSpWg2X06mM2ERTLPNLGs8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier Cc: Sebastian Ott , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, James Morse , Suzuki K Poulose , Catalin Marinas , Will Deacon Subject: Re: [PATCH v2 4/6] KVM: arm64: add emulation for CTR_EL0 register Message-ID: References: <20240426104950.7382-1-sebott@redhat.com> <20240426104950.7382-5-sebott@redhat.com> <861q6irj2t.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <861q6irj2t.wl-maz@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240503_102758_356091_2CEEE3E7 X-CRM114-Status: GOOD ( 18.40 ) 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 On Fri, May 03, 2024 at 04:50:02PM +0100, Marc Zyngier wrote: > > Marc, I know this goes against what you had suggested earlier, is there > > something in particular that you think warrants the consistency > > checks? > > The problem is that we have a dependency chain: individual cache > levels are validated against CLIDR/CCSIDR, which are themselves > validated against CTR_EL0. > > Change one, and everything becomes inconsistent. I absolutely don't > trust userspace to do a good job on that Violent agreement on this point, heh. > and not validating this will result in extremely hard to debug issues > in the guest. Which is why CTR_EL0 was an invariant the first place, > and everything derived from it. Sure, but userspace can completely hose the guest in tons of spectacular ways, I don't see why feature ID registers require thorough cross-checking of relationships between CPU features. We already fail at this. Just looking at ID_AA64ISAR0_EL1, we do not enforce any of the "FEAT_X implies FEAT_Y" relationships between all of the crypto extensions. Userspace can also setup ID_AA64MMFR0_EL1 to advertise that no translation granule is supported by the MMU. I agree that KVM needs to sanitize feature ID registers against the capabilities of hardware + KVM itself. Beyond that cross-checking userspace against itself is difficult to get right, and I'm worried about what the tangled mess will look like when we finish up the plumbing for the whole feature ID space. > Take for example CLIDR_EL1.Lo{UU,UIS,C}. Their values depend on > CTR_EL0.{IDC,DIC}. SW is free to check one or the other. If you don't > have this dependency, you're in for some serious trouble. Right, we absolutely need to sanitize these against *hardware*, and using CTR_EL0 definitely the way to go. Userspace cannot promise a stricter cache coherency model than what's offered in hardware. Making sure userspace's values for CLIDR_EL1 and CTR_EL0 agree with each other shouldn't matter if we've determined hardware coherency is at least as strict as the model described through these registers. Without the cross-check, it would be possible for userspace to setup the vCPU as: - CTR_EL0.{IDC,DIC} = {1, 1} - CLIDR_EL1.Lo{UU,UIS,C} = {1, 1, 1} But we would only allow this if hardware was {IDC,DIC} = {1,1}. So while the values presented to the guest aren't consistent with one another, it seems in the worst case the guest will do I$ maintenance where it isn't actually necessary. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel