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 EA254CDB47E for ; Thu, 12 Oct 2023 14:48:50 +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=pB0V5rFQPpschNv43YS88/BpwhKmpFKXcMHJ3HGnGi4=; b=SNV6lGr99ri19y otrvvQKr1aqkLQ+wx8QMLVu+2KavcAvJfC4JUHerrXZQE8r1UPlaZjDK7UB9C+th5XAFsu4n10oXJ b439ycI54zpr5ZJeZUfuUsLKMHWaQr5o4gN64SkaI4an6KJBIx5kk/v8nrjsVpAw8hZ4zqDtzutPo xtIwV8UD+/m9LZGacWrENlA4pri9UhCoGMq20wHTCDqMf6V28D8qznfak3Y2bVyvwdGSqppXdjlli pOfPUdGLCFy7fzwQDf+uGVU0raeWP+6GQerLyS7i8utoHqYUXfAD0Li/14JmYPmYqhxDF/LcUkWCO 7y3qSYHLb1Sqk1E7p/ug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qqwz8-001DK8-21; Thu, 12 Oct 2023 14:48:22 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qqwz4-001DJP-1t for linux-arm-kernel@lists.infradead.org; Thu, 12 Oct 2023 14:48:20 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id CC423CE28CB; Thu, 12 Oct 2023 14:48:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C4EBC433C7; Thu, 12 Oct 2023 14:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697122095; bh=iZPYvU5wRljfApCM+MJ581owf29pPt1A+Y/BqRAY+FE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AZNUnXC1YMmjFRqVniBnW419vtLsGYUrow79j6TNfhCrFDGuF9rRWfIhvSl6PXOQQ QlxMhbim0buZILGg9x254gcDzAA8uXbN2gl9sLMQdtZQKHLdqKGRv4vs57zRG4BBj8 bXHZTOeNMsrpzuPQKtTExlGtpRtmZawU4lCfhv5iQMDnwe21bUy/k8bWm81aSOOqPe dCpw/6x6ixPvpOCPg8rdcXZNZ/arpenL/pyzZSoyPQb8nuYxonJ0DbpEuIrm3qh/i1 YDFsQ71W+evua2BfFNImFU7X+t9CIDoFzcn9ytjtnSyCuCKPt099BMfkeF7DPWKWFD Kn5fFXtEV1djw== Date: Thu, 12 Oct 2023 15:48:08 +0100 From: Will Deacon To: Catalin Marinas Cc: Lorenzo Pieralisi , Jason Gunthorpe , 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: <20231012144807.GA12374@willie-the-truck> References: <20230907181459.18145-3-ankita@nvidia.com> <20231012123541.GB11824@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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_074818_965550_CE80203B X-CRM114-Status: GOOD ( 29.88 ) 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 02:53:21PM +0100, Catalin Marinas wrote: > On Thu, Oct 12, 2023 at 01:35:41PM +0100, Will Deacon wrote: > > On Thu, Oct 05, 2023 at 11:56:55AM +0200, Lorenzo Pieralisi wrote: > > > For all these reasons, relax the KVM stage 2 device > > > memory attributes from DEVICE_nGnRE to NormalNC. > > > > The reasoning above suggests to me that this should probably just be > > Normal cacheable, as that is what actually allows the guest to control > > the attributes. So what is the rationale behind stopping at Normal-NC? > > It's more like we don't have any clue on what may happen. MTE is > obviously a case where it can go wrong (we can blame the architecture > design here) but I recall years ago where a malicious guest could bring > the platform down by mapping the GIC CPU interface as cacheable. ... and do we know that isn't the case for non-cacheable? If not, why not? Also, are you saying we used to map the GIC CPU interface as cacheable at stage-2? I remember exclusives causing a problem, but I don't remember the guest having a cacheable mapping. > Not sure how error containment works with cacheable memory. A cacheable > access to a device may stay in the cache a lot longer after the guest > has been scheduled out, only evicted at some random time. But similarly, non-cacheable stores can be buffered. Why isn't that a problem? > We may no longer be able to associate it with the guest, especially if the > guest exited. Also not sure about claiming back the device after killing > the guest, do we need cache maintenance? Claiming back the device also seems strange if the guest has been using non-cacheable accesses since I think you could get write merging and reordering with subsequent device accesses trying to reset the device. > So, for now I'd only relax this if we know there's RAM(-like) on the > other side and won't trigger some potentially uncontainable errors as a > result. 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. Obviously, it's up to Marc and Oliver if they want to do this, but I'm wary without an official statement from Arm to say that Normal-NC is correct. There's mention of such a statement in the cover letter: > We hope ARM will publish information helping platform designers > follow these guidelines. but imo we shouldn't merge this without either: (a) _Architectural_ guidance (as opposed to some random whitepaper or half-baked certification scheme). - or - (b) A concrete justification based on the current architecture as to why Normal-NC is the right thing to do for KVM. 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. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel