Received-SPF: pass (google.com: domain of linux-kernel+bounces-37605-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 24 Jan 2024 15:42:27 -0400
From: Jason Gunthorpe <jgg@nvidia.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yan Zhao <yan.y.zhao@intel.com>, Kevin Tian <kevin.tian@intel.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.01.24 - Memtypes for non-coherent
 DMA
Message-ID: <20240124194227.GK1455070@nvidia.com>
References: <20240124182444.2598714-1-seanjc@google.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240124182444.2598714-1-seanjc@google.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?rSvRDxqwTo8NgMLe4BOOcmNKoIyMsqY6hOHzm+wXAvzQ82APPy5Kd/pccmIW?=
 =?us-ascii?Q?o5ws9mtG70p0RyDUHQDkXXrAmZEHAF0xCSNOaBB7wqVGE/DgeCUtpcepaPYq?=
 =?us-ascii?Q?DsmfRZJW6WWq1ULpVp7E4Xu6jvYhwzYyW+Eayy4SURvp+nJz4ZoGnUo7X2e1?=
 =?us-ascii?Q?ueSIc9K6ReYhNHaBGwo1xCJdGvjGtfZCmZkY/tEwBktpqBY80IuSbsuNS78E?=
 =?us-ascii?Q?VUdAoFuU/zE3PSrfRM5FKblBDFBkNwBGd6sDzX0XUtpk5skYoAY8BzoScMem?=
 =?us-ascii?Q?NLR3oULYa44vlOOYF4n8RESggTvEIwX8N7fBnfbIyo0qEUaOnJbPdWGToB7x?=
 =?us-ascii?Q?vnNnAiY5P68rKkbJbeLCjXEbPzADDp9QD/dcYv0MyPrMEJd4XXlFolHt0BI8?=
 =?us-ascii?Q?fGocEaVjrFAY8pezoGnzJtOXdgM1g2638pa131WXkfqoqL0WzbeiSrr4ERuc?=
 =?us-ascii?Q?CysBebDC6X7v8TDO2D47g0B1ZMBmfPaEnHCHKq0TCwNoDHz3SpAhGj2tagVX?=
 =?us-ascii?Q?a2tAUV3HRjBJmvm+y7ZZxEUNUuS8z/CnmWMU0TeanQxK8DXhFmvyzST0xh9L?=
 =?us-ascii?Q?5Dl1d5mcpR9AgGHwTJyKoCHShQ+clcgXWYNb2ljOMZHn7/Oz9ojOFXA7XxGb?=
 =?us-ascii?Q?BwUb7iXOI2R8u7UVLoRJuoTghhk3MHVmxYpCJoqDHSHNx0QMQVzshPu3K5IT?=
 =?us-ascii?Q?g/dp+lHvCU6xhOckM7lMFdS95zxB9TAmZE1T+o3gvDhfmIN4sdQ4acHGPS6T?=
 =?us-ascii?Q?QEOngGvoKeeCbstaJdtXro+6gvUrRXX2R4zETr5HgvvA+GStcKCJfuPqrBFi?=
 =?us-ascii?Q?kQK4BBxfoyIdOfsYGhFb9bCejhxsS0NC/y1GbCHEwUDC/Yf+5kkM3mxwPBda?=
 =?us-ascii?Q?8bEEcL+bzWUFYlmkytMQ2KVNM5P2+EmC6WLRYtlPyl85C78flczRB3Bseugb?=
 =?us-ascii?Q?ttc3s2xSW0+Tafw+lWGc0c60NfoUbIZSPNNNJ6qu1VPRNtSpkmX6HovPiDmg?=
 =?us-ascii?Q?+Kb41PYV5rBdbJ4RMqN57wyNOhd6iB5wr0RZsdunfuWbOBDtobR1Bqlvy+RU?=
 =?us-ascii?Q?AKXSQ2qWOKYBRl4cSV3B+mZFCBIPfknMB+CgvFVuINgFwut7u7rdcP2Y62dR?=
 =?us-ascii?Q?pd+j6R6sW7z5f8uy+7GDRalJSSTeAHd6yvVZYyBPBfdryGVdNU3sUYg93E9i?=
 =?us-ascii?Q?n0alyWg+pdf7LuWe0V+3MRS9g/dk4wfzwy6kFXJncC1opyHC+YuFmPrcpQfS?=
 =?us-ascii?Q?IBZgcw4eE0lsWt6axS1cWWpxPw3F+y6Js3K2FQflxtNs6gVzLKqdBhwZf648?=
 =?us-ascii?Q?lXeyw+FA9kQpyU69VXfOKfxGo2x14mGxzGLRTpU0PIOyxsLDeSOLjRBS0mbW?=
 =?us-ascii?Q?t/BU+xQX5UqV65V2cFXOjKqrUGcoHpyBdY5Deauf0OlTlu09Mgz849TLkoQo?=
 =?us-ascii?Q?TIjcq16S65qs9IIrUaVQo8ObOxSZYvEMPkMkzI6FYZi8DdTWfmf84OJuOxP2?=
 =?us-ascii?Q?lqHFiVPzi2RKO9ILRU3bP3U0JQBsDjnMVwyfroMNNRSr7ybGjODbry77Rf1M?=
 =?us-ascii?Q?3eJ/cgozfnFHDBMS3FCqRzSQvOZkswDl6GxC+bIJ?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c248c0ef-09d5-417a-7a8c-08dc1d1499ac
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2024 19:42:29.5615
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: qnqtflLlQqVHpVW3qgLYGhgJCJL+bIQiyrctoUXIVsWs6ab2wIOl+pd7WCCYtlJw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB5388

On Wed, Jan 24, 2024 at 10:24:44AM -0800, Sean Christopherson wrote:

>  - ARM's architecture doesn't guarantee coherency for mismatched memtypes, so
>    KVM still needs to figure out a solution for ARM, and possibly RISC-V as
>    well.  But for CPU<->CPU access, KVM guarantees host safety, just not
>    functional correctness for the guest, i.e. finding a solution can likely be
>    deferred until a use case comes along.

Regarding the side discussion on ARM DMA coherency enforcement..

Reading the docs more fully, SMMU has no analog to the Intel/AMD
per-page "ignore no snoop" functionality. The driver does the correct
things at the IOMMU API level to indicate this.

Various things say SMMU should map PCIe No Snoop to Normal-iNC-oNC-OSH
on the output transaction.

ARM docs recommend that the VMM clear the "No Snoop Enable" in the PCI
endpoint config space if they want to block No Snoop. I guess this
works for everything and is something we should think about
generically in VFIO to better support iommu drivers that lack
IOMMU_CAP_ENFORCE_CACHE_COHERENCY.

ARM KVM probably needs to do something with
kvm_arch_register_noncoherent_dma() to understand that the VM can
still make the cache incoherent even if FWB is set.

Relatedly the SMMU nested translation design is similar to KVM where
the S1 can contribute memory attributes. The STE.S2FWB behaves
similarly to the KVM where it prevents the S1 from overriding
cachable in the S2.

The nested patches are still to be posted but the current draft does
not set S2FWB, I will get that fixed.

We may have another vfio/iommufd/smmu issue where non-RAM pages are
mapped into the SMMU with IOMMU_CACHABLE, unclear when this would be
practically important but it seems wrong.

Jason