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 9D4B3CDB46E for ; Thu, 12 Oct 2023 16:40: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=tVQAo0PHkJyeAI6rsRFcjxVwAHiwZqA/EsLCjAFqpcE=; b=YQ39T0sWEy5CH/ KYfM6tXnrw/YVNRbkQtRaspte3WSFK2vlm6h2PKJSrlzn4euYRpoTUU083Gyx1kJjKXswu5PbfjbE DJdxsnMtdawm9w1aCS30SZvPBalq9fXEyi5NK9U32VZWwMrRufvu65zmuBk13+qaHXNATSm0xiiZN iL2TK3z3IDl5h8SqnUdI/unYOiORcH3BDuQQkLMYWDwlXg1akznfKCzYw72y3j9fY7f5j8RUZ3Bid Tppnq0Btf7RxbPmHQseYmgw0hPv4D479E6kW0ldl/v/R56/vS5Eqk25evEPLGoBpJ4l1FAL4rGZCi iKTT9F5Eq27ufNz6+fHQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qqyiu-001RKF-1M; Thu, 12 Oct 2023 16:39:44 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qqyiq-001RJY-35 for linux-arm-kernel@lists.infradead.org; Thu, 12 Oct 2023 16:39:42 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 2ED3FB8239A; Thu, 12 Oct 2023 16:39:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 256E0C433C8; Thu, 12 Oct 2023 16:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697128778; bh=nmKoxXIpfilzAZLTQAUFdY/ZQ+BuKyRRQ73Ee6ZQiiA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ebsMJVckreTvHUZVjLCuOTn9Wp8fV/+EF1ukRSr9CPFnwEfMFBG5/w/qpDTO+dVgK zNmdKE9/Lrs31IpLCU9hPX2obqlst/bhu4JjbHEFaHEvepsfMn1405ZSTyqPQmUPf1 eo3A8iBlCJzL9DqU89Y/gp4kMM8xFDCFkduwC376TjPFl/Zmu0xtx544kYYNsFMVy8 w7zxDrjVcLakYrDg1eV4LvXdo+sBVypMqsoiQiU4mQb40453pltGUTDPiblNdZMCmu 0sGXkmCbJcXbI6bK4a6NvWKIWvWbuMbciQ0XKWd/pKb589JNOg48GJ69xqkevUKpdP rwrnMZJ/E2hvg== Date: Thu, 12 Oct 2023 17:39:31 +0100 From: Will Deacon To: Jason Gunthorpe Cc: Catalin Marinas , Lorenzo Pieralisi , ankita@nvidia.com, maz@kernel.org, oliver.upton@linux.dev, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/2] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory Message-ID: <20231012163931.GA12592@willie-the-truck> References: <20231012123541.GB11824@willie-the-truck> <20231012144807.GA12374@willie-the-truck> <20231012154439.GM3952@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231012154439.GM3952@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231012_093941_281464_4951C388 X-CRM114-Status: GOOD ( 24.71 ) 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 Thu, Oct 12, 2023 at 12:44:39PM -0300, Jason Gunthorpe wrote: > On Thu, Oct 12, 2023 at 03:48:08PM +0100, Will Deacon wrote: > > > I guess my wider point is that I'm not convinced that non-cacheable is > > actually much better and I think we're going way off the deep end looking > > at what particular implementations do and trying to justify to ourselves > > that non-cacheable is safe, even though it's still a normal memory type > > at the end of the day. > > When we went over this with ARM it became fairly clear there wasn't an > official statement that Device-* is safe from uncontained > failures. For instance, looking at the actual IP, our architects > pointed out that ARM IP already provides ways for Device-* to trigger > uncontained failures today. > > We then mutually concluded that KVM safe implementations must already > be preventing uncontained failures for Device-* at the system level > and that same prevention will carry over to NormalNC as well. > > IMHO, this seems to be a gap where ARM has not fully defined when > uncontained failures are allowed and left that as an implementation > choice. > > In other words, KVM safety around uncontained failure is not a > property that can be reasoned about from the ARM architecture alone. > > > The current wording talks about use-cases (I get this) and error containment > > (it's a property of the system) but doesn't talk at all about why Normal-NC > > is the right result. > > Given that Device-* and NormalNC are equally implementation defined > with regards to uncontained failures, NormalNC allows more VM > functionality. > > Further, we have a broad agreement that this use case is important, > and that NormalNC is the correct way to adress it. > > I think you are right to ask for more formality from ARM team but also > we shouldn't hold up fixing real functional bugs in real shipping > server ARM products. All I'm asking for is justification as to why Normal-NC is the right memory type rather than any other normal memory type. If it's not possible to explain that architecturally, then I'm not sure this change belongs in architecture code. Ultimately, we need to be able to maintain this stuff, so we can't just blindly implement changes based on a combination of off-list discussions and individual product needs. For example, if somebody else rocks up tomorrow and asks for this to be Normal-writethrough, what grounds do we have to say no if we've taken this change already? So please let's get to a point where we can actually reason about this. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel