From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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 65DC51B4223 for ; Mon, 5 Jan 2026 18:55:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767639305; cv=none; b=Yg68oA6l+D/1fmnO/aulN7o8QzPTmOZlAdoQqUmN+6jP/YDdwSw9An4nwXkS3Wi6RaODeHKuhck/mBcZDBKUvs+IfelONlsvScg9PFmeXqOjC4P2ao/J+CNBrs+1vaLV4w+WzGWz8nSPDKl/JCyhAU4xVPSStIU29wEFc9kXKPI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767639305; c=relaxed/simple; bh=8N6sbBAWid/ZYJztu1ECpBF8QM5YL+5wF3MbJNf6KgY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lpmAkZMVXoHAwou13L3k+bdT9I0GsTNiv8YyUnXoEquY/mRVOBIRIT8//0CyheWLPCkZkBWj9BtZCxxsFmmaJokQcrh0f+eMLsC2P8n5/rz9sUGIQ+SoKCPnUoQKq8nkMlGpsH/tZS3643M8lI3H2PYYO4LUlnQwQqCokP3ZAKs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=fjFoeiX8; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="fjFoeiX8" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-7b8bbf16b71so290438b3a.2 for ; Mon, 05 Jan 2026 10:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1767639304; x=1768244104; 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=5DpxS8rpJviMrwQBnUs6BNFBrH4xHFjBHXZzxcPZ11E=; b=fjFoeiX8aCufS/DIdyGwhvDJ2TrD0mTjQtgvVw2Kt/WrG3GSuur/HrqhgFEWN1/Ak5 4/QjavY0Ey9Q1WJaK+Xw0G/+/c9EqLvA9ES2D7WNAA3a7BwT47hwQZUJynlNQ8c5CrHR w2vliK+z7s3SJN3IhGIeYX04TiK3mKFilr91c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767639304; x=1768244104; 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=5DpxS8rpJviMrwQBnUs6BNFBrH4xHFjBHXZzxcPZ11E=; b=PaHVMdG9yqWGjlEEIRi9Gb9lsuptVqdS+QX4auvjYjtekbb3kZ6HPv7NTRjuboC2qv 4iReLEzfXXv/awBO8guGRgEhGohqr0kpO7Mj5j7IACyppC5RxEIP/Hj6eFBqPsr62nSc xFYBaMYX5LTB+js3q1j9jftyondkwwR7Eb8rHq979LwuUe4GBQtD6qhgVWGgcc46PHfV JN2/tQisYY416tWX5nkVHuULLUoYI7IpJuLe9fe4D+TNJfkFw/K5C+JNqTdDeScoR16W Tk1HNACsSdMoVsuFg2ARGSbISLzpoyNWbCPGYPfGd4/zi4sLOZQubajXfXzMEmpV4/Vm arDw== X-Forwarded-Encrypted: i=1; AJvYcCW1wv9rcRQomosRIfhBc5iid6wkcmKkB3Jf22gLRBOWR9x2LwsTD/nnWGAtjX33s3HF4QoaFRvwnT5gObA=@vger.kernel.org X-Gm-Message-State: AOJu0YxaUUhFwarJlLtzAHCWZkoPy3R83WVYsN21jKEpngMMUd6EkDuv eDjZaMb2U0DxkKmhbEnWZNkWO+UzeaiqHkCGEa6UerFBJOD6duVoWexIFkiHRNk0JQ== X-Gm-Gg: AY/fxX72M7JtvWSBtPgAZer1kEUHhcgvHWxSljUnGaCtAh5fAm5gU3HNdNfgPGSsysQ ixhiXKtAhNav9zvkcNV2sO4GLoHBmg/cuEb4uelT6VvqiX8atj6ilYZYKEr5L26s1yejArRjZJy LfPuu0MM1jplGznpcxHQcL3h60yxU8K0hOTtRkIKGYSHqAtbtTfq9CgemCaL8uj1YzZsyxTIZwt fpZhaWkzAw6fvOen1JrSxt57gepsNSzFVhAiNjcMyfM1Ok0bulh1fGcdBqkCKOppB2AeaVszCjn fMDPubuMxF8QqyzmVwobeHMDqWix2o0OKpLs41mSxUHZjoMSrWnpT5TI7ZPjacSn9OPuwy/aJa0 hzl0BY/h+x1/4xtA4Mc4n9hDI1OFM1n5YCI1+Fm37fV56wb0RZfNRJcqSniZevPVU0c0h4rpdQ4 SGjzvaI1l4 X-Google-Smtp-Source: AGHT+IGmDE0QeurRLjjRHeAoA4yBYARtAMlpXceX0Y11k7mpPzrXKm6iX0itkPmBxWioX0MmbudKnA== X-Received: by 2002:a05:6a21:6d8f:b0:35e:7605:56a4 with SMTP id adf61e73a8af0-3898237c8b5mr235964637.51.1767639303711; Mon, 05 Jan 2026 10:55:03 -0800 (PST) Received: from google.com ([2a00:79e0:a:200:1194:8740:be25:ee08]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34f5f8afba8sm68540a91.13.2026.01.05.10.55.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 10:55:03 -0800 (PST) Date: Mon, 5 Jan 2026 19:54:53 +0100 From: Dmytro Maluka To: Jason Gunthorpe Cc: David Woodhouse , Lu Baolu , iommu@lists.linux.dev, Joerg Roedel , Will Deacon , Robin Murphy , linux-kernel@vger.kernel.org, "Vineeth Pillai (Google)" , Aashish Sharma , Grzegorz Jaszczyk , Chuanxiao Dong , Kevin Tian Subject: Re: [PATCH v2 0/5] iommu/vt-d: Ensure memory ordering in context & root entry updates Message-ID: References: <20251227175728.4358-1-dmaluka@chromium.org> <20260105181200.GH125261@ziepe.ca> 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: <20260105181200.GH125261@ziepe.ca> On Mon, Jan 05, 2026 at 02:12:00PM -0400, Jason Gunthorpe wrote: > On Sat, Dec 27, 2025 at 06:57:23PM +0100, Dmytro Maluka wrote: > > As discussed in [1], we don't currently prevent the compiler from > > reordering memory writes when updating context entries, which is > > potentially dangerous, as it may cause setting the present bit (i.e. > > enabling DMA translation for the given device) before finishing setting > > up other bits in the context entry (and thus creating a time window when > > a DMA from the device may result in an unpredicted behavior). > > > > Fix this in the same way as how this is already addressed for PASID > > entries, i.e. by using READ_ONCE/WRITE_ONCE in the helpers used for > > setting individual bits in context entries, so that memory writes done > > by those helpers are ordered in relation to each other (plus, prevent > > load/store tearing and so on). > > > > While at it, similarly paranoidally fix updating root entries as well: > > use WRITE_ONCE to make sure that the present bit is set atomically > > together with the context table address bits, not before them. > > The PASID entries should not be manipulated 'livel' in a haphazard way > like this in the first place! > > Like AMD and ARM build the new PASID entry on the stack and then it > should be copied to the DMA'able memory in a way that is consistent > with the HW's atomicity granual, paying attention not to 'tear' it. As I understand, the "consistent with the HW's atomicity granual, paying attention not to 'tear' it" part is already fulfilled for PASID entries (and with this series, for context entries as well): static inline void pasid_set_bits(u64 *ptr, u64 mask, u64 bits) { u64 old; old = READ_ONCE(*ptr); WRITE_ONCE(*ptr, (old & ~mask) | bits); } I've been assuming it's ok to manipulate other bits in place as long as we take care to only do that while the present bit it cleared (i.e. while the entry is ignored by hardware)? So IIUC the only problem with this approach is the redundancy: we do this READ_ONCE+WRITE_ONCE for each invididual field in a PASID entry. So while I agree it would be more more natural to build whole entries, and the existing way looks strange and not the most efficient, I'm wondering if it is causing any actual correctness issues (apart from those addressed by this series). > This manipulate-in-place is just asking for trouble, and can never > support replace or full viommu requirements.. :\ > > So while it is perhaps an improvement to do this work, it would be > better to fix the root cause issue if someone has time.. > > Jason