From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 C72C831B123 for ; Mon, 5 Jan 2026 20:05:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767643553; cv=none; b=rdawAKO6L6VH4Q18YyN9t05Gh4JQOyzTP1WPJpVPJDOi1APXAPG6EjMghQOw59t6yMs3DbbQb9TJiJ3NIGMz9vABJGV4YmeXxpUJmcRrL+JMittND8dgWDSMMf8wbGOo/HUDnUh/zKIA14HIvXeEoawWG4TAW6RxZtZfE5xgEeQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767643553; c=relaxed/simple; bh=8onnp3FD4r4gnlk8NIzgK2RDbreeCwfl2l8x2h8gxzw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LbCTMf/duq122SVntRCa4BRIcQZJQIynztcPBqi/gfWO0S6bHRf8zComr+19Xzyyl6sZmuXfoH4sPAQODZnY0kMNtiOFJAjWSsDEOtdFYB7RMEbgj4Pq8c0AEugA+RhP6dJCc+1H+28bvfqaChX4ddGZuvnJrXeR9JZaY/G1Ajw= 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=ntqqsW7I; arc=none smtp.client-ip=209.85.208.41 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="ntqqsW7I" Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-64d30dc4ed7so512108a12.0 for ; Mon, 05 Jan 2026 12:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1767643544; x=1768248344; 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=ew672O/Nts/+UtFO3wzfg5UyDse9xguRdTmeMwK7afk=; b=ntqqsW7IOcwyXQEntAW2wjwGAfZW7BdiNL5DIaTRBUubVrA4QYZcFXYm7UeC/d2mDg EwhgQKC7Bht4r3K1ksifIS8vg4xCJYLRnXxgT+8o69O4u1WJapdoSdR4kw/jJ5MCKMGX Fd4O3tvy0lfpRo2FGV3T+WKDoUwU9vCC2LSlU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767643544; x=1768248344; 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=ew672O/Nts/+UtFO3wzfg5UyDse9xguRdTmeMwK7afk=; b=bAccRYO4q1tlsnlTT61aNqWDs0mj3n0p8EyGh/2hSQiDZN91jbX3G0WOdKOGRITfWg H4U3ba3D5FfjS1bKK9o2DVc6dRD+545mgLhbImXQt+QdSFWxjy4JoKZErQN/WDO6hxZU pb+BA+y9xkoewYswNB24VlofwM14fOx8reGQrvurCFdz1LYEo9rnyeq9HFsrr0YnhX/0 hhYUSzYD9pquZDP4nlzKFzD1eHZ0drMFa147aG6zC47rSpaxy0yGcChX/tkF0AaS49tW kiY6n0B00I7pGXMxsNaSTzTAcU02WIYTatoHKIpUTsyxmiyW9Y9hsEr6mTGNdH9uuB1v 6Ewg== X-Forwarded-Encrypted: i=1; AJvYcCWNUEOJBxSUtRxx/YTdBMrawSqZZbjDlCnXF9SoIrCqsZA9r7pUDskpChYE7CSpgZwLbllF40ISXQHVYBY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2AL9QFZvjBybgc7Dpee8H/Em7RkoI5wuxFRjvY10YUM+jmfFu qE0MQxekc1JSqLcntxd8z0W38m7xNrpg0ecrsvZ+5nW/jsr9I/rUlxVdy2VeV8dYEg== X-Gm-Gg: AY/fxX6Hi/w6DmpYrNf3k7vrV6myZZuZkqapLmXd1bFEeUJ2Cm3SbtynqVGUp894g1c XGZOdYrIhqntaqzbMtgvDBhKRwBhqZwXaCQF2Tf/0SUAiLrp4YDHwJ8CQZAqw88/M/P3g97MK1t G3tRag1aVCNheuE/C5/s3OeFH3NYjHXwc/sfUO2sZMq5DXLSqsIEQvzOrLxCtQtt7tR5R9JlOlQ UYmoGccVV5kfDpHsjvADGVCjFmekbwaCmRTw3WfLWGl88tZT9jIOFmBib5H1UkKc5g0BvPtnvL7 sMsaDpQFNiEClHue+ZWpswyH2vX6lUz/F5aPbLOrJOFhONcKjFoQGfUrCfZV2rNDtkw7mRD6KNF BOnPZc83Dqj4qQ+7m5v/PzUrZB9kRVaAxjrfgLZ08T5Fc/7K/NpbVkBYmrMwOcDTBDTKNM/9UFz nUG+14ILtd X-Google-Smtp-Source: AGHT+IFnoPKyqXFFa+aZwlgF/IhySxChhcDm/NAxdw2bW0ctWFC4XdEoMeB5iCV0Qzqx6MBgcjekTw== X-Received: by 2002:a05:6402:40d1:b0:64b:5c4e:e695 with SMTP id 4fb4d7f45d1cf-650797a069bmr507356a12.29.1767643543910; Mon, 05 Jan 2026 12:05:43 -0800 (PST) Received: from google.com ([2a00:79e0:a:200:1194:8740:be25:ee08]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507bf66214sm304743a12.27.2026.01.05.12.05.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 12:05:43 -0800 (PST) Date: Mon, 5 Jan 2026 21:05:36 +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> <20260105191410.GJ125261@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: <20260105191410.GJ125261@ziepe.ca> On Mon, Jan 05, 2026 at 03:14:10PM -0400, Jason Gunthorpe wrote: > On Mon, Jan 05, 2026 at 07:54:53PM +0100, Dmytro Maluka wrote: > > > 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)? > > If these are only done while non-present then the only issue is > missing a barrier before setting present, that should be a one line > patch, no? Yes, a barrier, or alternatively WRITE_ONCE for any updates of entries. The latter is how it was already done for PASID entries, before this series (so IIUC for PASID entries there was already no issue), and my main goal was to fix the issue for context entries as well, so I just did it similarly. > > 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. > > You don't need READ_ONCE if there isn't another thread concurrently > writing, Good point. But it was there before this series. > and WRITE_ONCE is pointless if the HW is promising not to > read it due to non-present. As long as we use a barrier. And IIUC vice versa, if we use WRITE_ONCE for any updates, a barrier is not necessary (on x86). And WRITE_ONCE for any updates (for PASID entries) is what was already done before this series. Although, perhaps even with a barrier, WRITE_ONCE is still desirable to prevent the compiler from doing strange but legal things that involve transiently setting and then clearing the present bit behind our back? (Not that I'm aware of any compilers doing that, but I'm no compiler expert.) > > 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). > > It prevents doing the replace operation, which is a correctness issue > for VMs. > > Jason