From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF26F3A0EA6 for ; Wed, 14 Jan 2026 15:50:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768405818; cv=none; b=D7GWkWbA1Z2p7npMtIIGMhqHxgmlWmF0OGTdFFH41A/JsmFGzi34qp2Jb8Oa2IUTEX2AhlPYtI1yGBWiAQ7dfF0i4JO/DoFM8R78xYhAE2eJwAu8xUYDpVFUqyqrEnV1Tgi3fkF/RIL5t+J2cXVwK+3UZWt+kOG+be95TbpFMu4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768405818; c=relaxed/simple; bh=N+tLMRmoiFGfxXzeaTMOxasVpQhTrHRdnrw+/3/mH9s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lKxOa/P+E9+MxN7azi/L5O4Uu9VBpXbDGV/eKUc6jhH31/R/bScTIEx5umH6DeHbt6yg6yPTlPCYdtvZbSiz9irufG/ItVXuWnBnc6EIOBFWIfPrkwHGNePOjjUr27aT0fzqbAcBXNWELRJjQeyK9cJDNaDPcUVc+WaiE1/+VEM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=wmeQpGDa; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="wmeQpGDa" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-29f02651fccso84765ad.0 for ; Wed, 14 Jan 2026 07:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1768405816; x=1769010616; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jCxOk+iywvSu8+CpqcXhukbgVIWbwqBDGWYpBD4H77A=; b=wmeQpGDarceOXDMnxADkbCVNIVc8+VXx3BJhG1CGR8waJu0yhzQE7hangHRogDRFMo UBzTEPrd9XC3gwhr6CcmXOEgGGQLA1aWgtfdcaKSWDKWn+UZae25MecgXSUWMaEu15OD Rm7i0so21riPquhFBSLi4++fb+1pe/9JjFKP4MKAKwwUP+Ec83H6ZDOMByX7qTvK/h5w vt3IvNoUk8D30cgf9u5H1yetRj6fCNb1CYnR7hqPn9HOsXjDaXvNPLZT8OZ8AG97/xm4 f0x6sGfRCMJRED15BineRNS0PfoCL3wcZSx8UlHY+aTlyIDLxLuq5Oi2IgOKH2nqCTPn xyug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768405816; x=1769010616; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jCxOk+iywvSu8+CpqcXhukbgVIWbwqBDGWYpBD4H77A=; b=nb9Zy7vnxOg3ZSnu+cEJ+aHtMPPUwFx+N2l5RPLm+LSEzbrHs4pBEJ/kOn4ZDnfx19 5IHLKK8DFOiarp2JjsMfi8Crq32TLehufozb1/ujVcVg4E6k/ADtGBHWGEIDNWz6Kb1z bjzSg9oFsfQgzpt5b1dHL2YR5s6s9LNUojbJwprkU55XJFJSyuaoNKCGJnpb7dnqFeSH Pd1wp8S20hckgZOmBSv+iAcg72SMEx+dNdh89XwRnsb9Qa2ENlkOZ0U7a4AXmO878AWS QzEuuksVvimcxKT+vm6xjJmbyEb3SctaYGDnfyle8YD6Y8ET8831WbbV7FTb5zLY2lOe N0fw== X-Forwarded-Encrypted: i=1; AJvYcCUB7EhJ82CP5wJ89NaI/HzseR/EI/4zgnLoONWBwz2Acu20RDfnColHOFqNM2/OxL5CPkJOIbOStrOGjIA=@vger.kernel.org X-Gm-Message-State: AOJu0YzldmWd4srKj9KoYUxUVbaGaT7X0O4sHTsxbS9dKQkkA8SmsR/g w6tTStJig3kdWzNlb/v54jk8cLLb7LbqNfp67H6Gvorvpf5KkU6fBxMfM6Lw2wv0GZH4gxDmdYF 2MdnV9Q== X-Gm-Gg: AY/fxX5v2hsggvWu4NxBFgUWEBLiP+Dxzh64Sr/HWX5E7jI/P78pvN4QCH97ZEl/JH6 QGpwzfdPmi+rlklQX1h4FZK6FlrGxeOtHimhvBa8Orpw93nxOangKC4C0R4dYCPPIEHEE+oVjJo +62st5lPFawc4MbUf0qllzFSVVUbiHs+knxl0fivzpylquCx1onkFN9lKSvlvOmy4HLIDnHgMv8 ci6WhZlPnqKiXZh5T7yUziSR/Ie2dXv7vzpcoNPKETUzeXTlpzeARAvGUIGBMVqOWgE2GMOWqTT r9EOpKaJhieIL4/MkiT3/HBsIw6vs2V57KmuVcoIwyPINhTR+xIdJ24d5oJrULh/+McR5ZZ4L8v 9ofVO8ZHza4Ke706ru5kCR4HaTFlA6kW+nNXVQfRde8JfyCdK/lAbrojlClYppiLg/VQHnksfLi du+0ZJxQIIpk+nGkktAHZBXgsjBKs0ugQnE4bxLjngbWb3ffG/ X-Received: by 2002:a17:902:e549:b0:294:f745:fe7b with SMTP id d9443c01a7336-2a599a25a6bmr3059615ad.6.1768405815639; Wed, 14 Jan 2026 07:50:15 -0800 (PST) Received: from google.com (222.245.187.35.bc.googleusercontent.com. [35.187.245.222]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35109c78f20sm2370400a91.13.2026.01.14.07.50.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 07:50:15 -0800 (PST) Date: Wed, 14 Jan 2026 15:50:09 +0000 From: Pranjal Shrivastava To: Nicolin Chen Cc: will@kernel.org, jgg@nvidia.com, robin.murphy@arm.com, joro@8bytes.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, skolothumtho@nvidia.com, xueshuai@linux.alibaba.com, smostafa@google.com Subject: Re: [PATCH rc v6 2/4] iommu/arm-smmu-v3: Mark STE MEV safe when computing the update sequence Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jan 12, 2026 at 12:20:15PM -0800, Nicolin Chen wrote: > From: Jason Gunthorpe > > Nested CD tables set the MEV bit to try to reduce multi-fault spamming on > the hypervisor. Since MEV is in STE word 1 this causes a breaking update > sequence that is not required and impacts real workloads. > > For the purposes of STE updates the value of MEV doesn't matter, if it is > set/cleared early or late it just results in a change to the fault reports > that must be supported by the kernel anyhow. The spec says: > > Note: Software must expect, and be able to deal with, coalesced fault > records even when MEV == 0. > > So mark STE MEV safe when computing the update sequence, to avoid creating > a breaking update. > > Fixes: da0c56520e88 ("iommu/arm-smmu-v3: Set MEV bit in nested STE for DoS mitigations") > Cc: stable@vger.kernel.org > Signed-off-by: Jason Gunthorpe > Reviewed-by: Shuai Xue > Reviewed-by: Mostafa Saleh > Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index 390446d259ab..ccd6357fa5a8 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -1086,6 +1086,16 @@ VISIBLE_IF_KUNIT > void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target, > __le64 *safe_bits) > { > + /* > + * MEV does not meaningfully impact the operation of the HW, it only > + * changes how many fault events are generated, thus we can relax it > + * when computing the ordering. The spec notes the device can act like > + * MEV=1 anyhow: > + * > + * Note: Software must expect, and be able to deal with, coalesced > + * fault records even when MEV == 0. > + */ > + safe_bits[1] |= cpu_to_le64(STRTAB_STE_1_MEV); > } > EXPORT_SYMBOL_IF_KUNIT(arm_smmu_get_ste_update_safe); > > -- > 2.43.0 >