From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 C5BEF335541 for ; Tue, 6 Jan 2026 13:51:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767707509; cv=none; b=CCnPS7dg1RPF42baDMghjVBLFqb5BSTNDcmb/z8mcEahLObKEmcZqEcaInwuJTtVYf8nbTkrffp/N7Nqwdl4NEiMnk9eYUtxwaet+6F1H0NlNv6x2O1PWrc5fkZ1bSWg1RoWM5XZuU2nCc1HZoxY4SX76Gws4W04un/ahabwdpU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767707509; c=relaxed/simple; bh=zXr+iLednLcYqiiAca5A60eK1ZlY/WKsuhkOhEKs29I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=exC/4U2qHCzxuFb9SLPKHya6TUyeX2i2vzP/fvoH188PjaKDWdUctqhKciuWMoTPUPqX2W/39MkEMqwqhd6/HBkdaJHoXWFD9GIZSMmHCIgfcXGQR+Wf5rFLGykhe2i58kicwOuJQg1mAT31FBiDLNYbRXbJVL9P9UPlffeLOps= 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=SOxkxm+0; arc=none smtp.client-ip=209.85.208.47 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="SOxkxm+0" Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-6505d3b84bcso1493196a12.3 for ; Tue, 06 Jan 2026 05:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1767707506; x=1768312306; 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=otgUQYuu5A+quca13KcoFdag1ptfaGsgiKQ3LYEpZIg=; b=SOxkxm+0XSHCIDVWnG0dNhEZU7RYyA6YVXAEHUrnMquXdg21D+fo9B87e3b0KsssQr XHCx8tXpDUfKtUyQKbSb3xkoqqHxtahHNuJ8u+yP3KW6BG1JYbnm/S9/1x8QCp6L2sk6 O1KV2tIqKlUgYT8g0VCmB6zK7o1iAG59ZhkWQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707506; x=1768312306; 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=otgUQYuu5A+quca13KcoFdag1ptfaGsgiKQ3LYEpZIg=; b=HEhs33dejG1ZtlbmAmvkUw7LjGWtGJGhCbz3sBfxJbIDc6JY6Z/OBA1S0DPNjAhwhp uU2GdSMBXcZV+y1fu+3sLiKyAkiwrzgZ1zeKDewUvva0HNeAruSfIVWxybXv3Hc0J2Yw b/4/4JU9CAW0yxrj58V/qhDFiwejL7TaeoyxOTp9CpXnIUghaobPYcyvFSlZwS7gJpc+ t61fda/KDNxXj0wQ7jku3K4c5hR3Da+UUfgHJXkutrs3oy2UWvAovrMrrWQzE2B1r37L ZTF0hKdDBmvB6UWFuxH8AeAjMSv+TC8YLkTRNtBuGYjdJ/1z6zzlRxpxVtsDhjhtClKR hQZA== X-Forwarded-Encrypted: i=1; AJvYcCWgC/U2fOCobuqRH8MBTEWAazCMGTPiMPZ6aMKAkpV4shIzBBm+WnVIDr56KlAqClZXv66mJ2/gHJhJoUg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx36jZu1Is8pWSpHsxRZ6t1WCKt5VA9olkEko9ogph4hz6rxxgq mT91vT99PNYNSK4xL/uXMYHN5O8U5Ze6ebXA265kzvaT8IjP6Rro34Tcv6Pq3FJ6KQ== X-Gm-Gg: AY/fxX6XxsMMJ8sO/gd+paKIY26SfRRAAy4n60g2BW+0zrzSQxoG1v4PgT+yiCXOVef YryI/1w8ezvEOfAwejOU31gIFJov51RimCB3AgyloNL4nicsNpfwyAcPyPB8hkuvIi5HJT8KkQg b3uztEcR06tSOn98Cfmi8mNwMrlE+n4qgpVQFc/aaBhTTu1FjdVWMHugjmpw7mo4YjKtyebx5js OiowpmmtWxZGdJ/F3wsX2DYvdN8Xb96TmoqPwohpFGO8X3lel4P3chIQ3etnKKWdXxqlx137ST8 oix5fHH6d+RwvP243Qo0eVq3WHKgMxYTEsk20pFL7yJ2DUOg51WCvdgQSA3UM2f87EKjZki4y9r yNznSX1PXnyUHp8aqAGmdbR9a6cRRJq7Og6hAYJ+OB5rHiXjo7gmi3hmGkAmPY0nBcqaG9hNtwh L+XxOdaPSx0HZ8GZ7A48Wy X-Google-Smtp-Source: AGHT+IHfs1NCiviorp5D5CPudHEDsr5xSrD8Y7TY4SpO2cO9ruMxLsgqkuvg/n976wFzlqh2m+mVBA== X-Received: by 2002:a17:906:ee81:b0:b73:572d:3b07 with SMTP id a640c23a62f3a-b8426adfea1mr342452066b.28.1767707506097; Tue, 06 Jan 2026 05:51:46 -0800 (PST) Received: from mitya-t14-2025 ([2a02:a31b:20c3:6680:43e9:5120:2208:3239]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a51543fsm232466266b.55.2026.01.06.05.51.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 05:51:45 -0800 (PST) Date: Tue, 6 Jan 2026 14:51:38 +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> <20260106001418.GK125261@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: <20260106001418.GK125261@ziepe.ca> On Mon, Jan 05, 2026 at 08:14:18PM -0400, Jason Gunthorpe wrote: > On Mon, Jan 05, 2026 at 09:05:36PM +0100, Dmytro Maluka wrote: > > > 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. > > That is an x86 ism and it shouldn't be needlessly leaked into drivers. > As this is not performance it should have the portable flow: Agree. And as a matter of fact, patch 4 in this series already does that - it adds a barrier before setting present bit, despite it being "redundant on x86". It adds smp_wmb() as suggested by Baolu but I can change it to dma_wmb() which indeed seems more suitable. (FWIW on x86 there is no difference between smp_wmb() and dma_wmb(), both are just barrier().) > WRITE_ONCE(non-present) > dma_wmb() > Regarding a barrier after clearing present bit - good point, I should probably add that to my patch 4 as well. Regarding flushing caches right after that - what for? (BTW the Intel driver doesn't do that either.) If we don't do that and as a result the HW is using an old entry cached before we cleared the present bit, it is not affected by our later modifications anyway. Of course we flush caches at the end, after setting the present bit, but that's a different story. > > 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.) > > You do have to write once the present bit, but not the others. The > dma_wmb() will make sure the HW cannot observe other states when it > observes present. I was talking about compiler guarantees, not HW guarantees. I mean: when setting some other bit in the entry before the barrier, if we do that without WRITE_ONCE, with a mere "foo |= bar", are we certain the compiler will not implement that as, for example, setting the value to 0xffffffffffffffff and then clearing other bits (for whatever crazy reason)? That would be still a legal thing for the compiler to do, in terms of its single-thread guarantees? So it still seems a good idea to use WRITE_ONCE (or anything not weaker than WRITE_ONCE) for any updates of memory structures used by hardware, to prevent such things? (And using WRITE_ONCE for that doesn't really cost us anything anyway.)