From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 1E4363A4AD6 for ; Wed, 14 Jan 2026 16:59:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768409950; cv=none; b=KJ07FElqeAFAnWf2uExh2MBmHYFmn4oIfBOtGBT7MnhInel/ny7wEZcP6VemenHkdhJuHYg4nyZxzVEaT3++KNVJNZJDHNDIb4CxFcioRSrppfjsF1rSBV4468KmPoCkgu2NadIb5RjgA+n2TAH1Ea+4EdyQ4Isf0TBUllW97SY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768409950; c=relaxed/simple; bh=DjpdDDJbM/IsjFMrq1EcksQWZkZ6ktdKQa8/EaVmO2c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R3zSFRwCnvS+Sg27buv2nonBS2Q3ajvA30PiAgKkACgS8Jp06vc/0tz9ncxBonXPVP8wiW2iVQlvKWYxngKuUCmbjSYRRtPBPusBGRQyYXdaDVtVYaJplghmfwMnxl/fyzOurNoFhs7mZF6xhdJkaN5XRc6/uppJ70GdL0+Nu90= 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=Ib//4gM/; arc=none smtp.client-ip=209.85.214.180 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="Ib//4gM/" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-29f02651fccso93815ad.0 for ; Wed, 14 Jan 2026 08:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1768409948; x=1769014748; 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=nvlZDl7Sj74xagDLD4MC5KELnDbe4Vh9GRDyybbfdBA=; b=Ib//4gM/STvvemJqfS0WYGH95C6NHQdMDmxSAQK13vQW3+N1u+amutqZDJ85GqpElL 4PQlv9Tc+vCr/N7nHgCmKAyG0MZFN+/y3Fk/WwHS8DVcJhUC9dN4M5H0L246aL2sD7aV 0ZqpShKTe0flzaxcYDKpa0ke596RLERIaRMUdvu0mJRyNDy5Bl+l/wBGoWa7h77zgjiw 2uI0jcgMym3yfKrIL9kjE7XjsX0m/droU3XQSfboI84tPdg3tFUUiutLm9bbKsGh8F9R o7oITv7UcF34yHAIOuVPrA1g9nXUIByRO3ogridfJuHyzpiayiCMaO67pA7gmdYeA/xq j+7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768409948; x=1769014748; 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=nvlZDl7Sj74xagDLD4MC5KELnDbe4Vh9GRDyybbfdBA=; b=dg8WYGVs1F3EomyA1tn3V9tNWsCQKX1SYWGMMTk1riIMANEZrPGHxzSjGOCioSqiY5 TcV7cqnWrBa7dJmIRjjkBxrg7c5jG91nbXIJB3ATKay3688KiBb8WyDEsgQqBxYrqVtZ YKzf8FJnb0j8P0WUM5SYnEIVYI/XGL1BoReH6OOhfuf6vxIxdM4SB33AiKUr33IBDO0l t4R8ccAaa8OzLwuVBf5go5xEHEvGOVj1LYJYF3W9IsVosoM4IkZaMJpdPSTx8YdrEwgO aF0EKM/isnRAXzMCF0kMTnDGdkUTSZu4OXI3MPseyUJrsGDDUZXO7E06f7dXDZwwXGt9 WprA== X-Forwarded-Encrypted: i=1; AJvYcCUX3mMDRfy0JI7g9eU07081jx8awMBqmJ1SqrZkIpNe3jKJzb+Qr92J65aeo2TCFSIezly8Rr3d+dpEKGk=@vger.kernel.org X-Gm-Message-State: AOJu0Yz370lV7D8KcSWfEgHOQKnQBSlIKotEioBXfzSUjLZ/QXeNPLv7 TxmyivUoCgII44TKXKm9sJTsYg5zxVIdC1O06mmEjA5M1VcXOZIx5KfHL9jpcQSF/w== X-Gm-Gg: AY/fxX5pCgIFUe0T4oRQbENdSpfnlwhgWDIivwhAGMaML0BiDnQfIxq3H6CdDtgTnrF g+w03kqSsjenL1w5aFb3zsRjYNOFth1NDGhChBkoTpQiDE6vkXw6owIgSLocDgK0PRizLl+8cqF lTgCtbyLUfWe/+KISbLA2qkpWHoRoXHoa8w0KMFvCsV4ARpKCJtRtKB95FyPk226zERScQ5Qj8F GqYmPH+f0Z4yL8QPUefzpLhwKpNnMH55qL/iVAQFme0i75vuH4CxTgVpn/xcTMnlRB5flyPmZQP On1AkiNylOgLeM0HuTNRmCEqjbcj2RH7PAXRbUJbWdct7kmLYZ6I0tLOKlMlDVI4y6ueeCCQYLZ rlNmPu1rddYlp7dS8JbWLLtB+Y2CkIW70j7AzdKuVgncQC/f0Mgyc/rqcDk6h1WX+HyGb2+Zu/R zcdYaSK9LMR6Mg+eq/V/0s16y2JDs7jVtOji9awcsUNDMakDXX X-Received: by 2002:a17:902:e890:b0:265:e66:6c10 with SMTP id d9443c01a7336-2a599a24a2amr3823475ad.4.1768409948061; Wed, 14 Jan 2026 08:59:08 -0800 (PST) Received: from google.com (222.245.187.35.bc.googleusercontent.com. [35.187.245.222]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-81f8e381d7csm135568b3a.0.2026.01.14.08.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 08:59:07 -0800 (PST) Date: Wed, 14 Jan 2026 16:59:02 +0000 From: Pranjal Shrivastava To: Jason Gunthorpe Cc: Nicolin Chen , will@kernel.org, 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 3/4] iommu/arm-smmu-v3: Mark STE EATS safe when computing the update sequence Message-ID: References: <20260114161557.GB961588@nvidia.com> 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: <20260114161557.GB961588@nvidia.com> On Wed, Jan 14, 2026 at 12:15:57PM -0400, Jason Gunthorpe wrote: > On Wed, Jan 14, 2026 at 03:58:03PM +0000, Pranjal Shrivastava wrote: > > > + > > > + /* > > > + * When a STE comes to change EATS the sequencing code in the attach > > > + * logic already will have the PCI cap for ATS disabled. Thus at this > > > + * moment we can expect that the device will not generate ATS queries > > > + * and so we don't care about the sequencing of EATS. The purpose of > > > + * EATS is to protect the system from hostile untrusted devices that > > > + * issue ATS when the PCI config space is disabled. However, if EATS > > > + * is being changed then we already must be trusting the device since > > > + * the EATS security block is being disabled. > > > + * > > > + * Note: Since we moved the EATS update to the first phase, changing > > > + * S2S and EATS might transiently set S2S=1 and EATS=1, resulting in > > > + * a bad STE. See "5.2 Stream Table Entry". In such a case, we can't > > > + * do a hitless update. > > > + */ > > > + if (!((cur[2] | target[2]) & cpu_to_le64(STRTAB_STE_2_S2S))) > > > + safe_bits[1] |= cpu_to_le64(STRTAB_STE_1_EATS); > > > > I understand what we're trying to do here but isn't this implicitly > > saying it is safe to transition hitlessly to any non-zero EATS value, > > including S1CHK or RSVD. S1CHK might have other config dependencies? > > Will pointed this issue with S1CHK, Nicolin has a suggestion to fix it here: > > https://lore.kernel.org/linux-iommu/aWarF90zBqxD0Gef@Asurada-Nvidia/ > > It would block RSVD too. > Ohh okay, sounds good then, my client dropped it somehow. I'll defer this to Will. > Thanks, > Jason Thanks, Praan