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 6CE20CDB465 for ; Thu, 19 Oct 2023 11:12:42 +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=itFaTOHkHZLvrZwkobpSSNGbJXQJ7uf67EPcCGMKQsY=; b=IJyHRGJWC36zPo vMUzT7J0PIxBTZvvQ8m2kUISsn05T7rZq+lotVfR3jiiq432QTz3AbusfSBxKCnx8AD8YkIVkC5U/ dn9JrBcMipLiI9ft0GWbmOa/PE9kzej8X/eu+LSzuBdmegswM8uJtvFf3KIY+E46ewQZOsEaHR9IF FQKP/mWqgrUc95SU86pRrXs3udimDUrbKRicgxnE6IwGnxOamU4IS1/h7gnkPa+TnleVa7AyqJaGk 7FV2o6RyuhBpj1c0QNqALRUN+Onz9BC8zelmLoeA98ipnO9kB4KMMMSWsBR5Cw4HPWpSJXNh1iqy5 hD0z5oS6UlaUqurKDBag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qtQwr-00H8Wn-0g; Thu, 19 Oct 2023 11:12:17 +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 1qtQwn-00H8Ua-0d for linux-arm-kernel@lists.infradead.org; Thu, 19 Oct 2023 11:12:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 817D0CE2B56; Thu, 19 Oct 2023 11:12:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6322C433C8; Thu, 19 Oct 2023 11:12:05 +0000 (UTC) Date: Thu, 19 Oct 2023 12:12:03 +0100 From: Catalin Marinas To: Lorenzo Pieralisi Cc: Will Deacon , 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: References: <20231012123541.GB11824@willie-the-truck> <20231012144807.GA12374@willie-the-truck> <20231013092934.GA13524@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231019_041213_410674_3A625503 X-CRM114-Status: GOOD ( 22.39 ) 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, Oct 13, 2023 at 05:28:10PM +0200, Lorenzo Pieralisi wrote: > On Fri, Oct 13, 2023 at 02:08:10PM +0100, Catalin Marinas wrote: > > [...] > > > Yes, we end up with mismatched aliases but they only matter if the VMM > > also accesses the I/O range via its own mapping. So far I haven't seen > > case that suggests this. > > > > > > Things can go wrong but that's not because Device does anything better. > > > > Given the RAS implementation, external aborts caused on Device memory > > > > (e.g. wrong size access) is uncontainable. For Normal NC it can be > > > > contained (I can dig out the reasoning behind this if you want, IIUC > > > > something to do with not being able to cancel an already issued Device > > > > access since such accesses don't allow speculation due to side-effects; > > > > for Normal NC, it's just about the software not getting the data). > > > > > > I really think these details belong in the commit message. > > > > I guess another task for Lorenzo ;). > > I will do, I start wondering though whether this documentation belongs > in this commit log only or at Documentation/arch/arm64 level (or both), > I am pretty sure this thread can turn out quite useful as a reference > (it is for me) if we manage to summarize it that would benefit > everyone. I think it makes sense to add something in the Documentation for easier future reference. We can also keep adding to it as we learn more. The commit log can be shorter in this case. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel