From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (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 33E1D34DCE3 for ; Tue, 6 Jan 2026 15:50:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767714622; cv=none; b=fJyU9ue7eQC6pos4TYZ2FZin8Zj198JGVRlTnMK8OnXU1nmKlD4ybzHbr7EndB5dOwArmgmA7NgE1LuQQEShhW8viCdZ2lWKxsMN+HqvhN6ZPpKbNMTxQYVnnMKj6P32h7VL3WpnqczDEg34gwaLuP9b/AEjok7qT+YJl6Bsg38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767714622; c=relaxed/simple; bh=b/zjggFl8/W6uEcltcHPtMmP86hS+JiDB4IS+bXA6Gg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ODyRvU2NBNyjIgs2ZKWLewLUS4ve/AMe/CTr6c7v20HihDmp/AAeZ9EGQTsagMmBKIpFfeGQXc9yKmf1q6QuQ1GdLJyxjRVAqjSIOsmGRZ+Yi9rKz6t3CDE+RwtDm96d02gk3WHk1CIxdbEC6HRZvGF65NAq8L/QaxtNbVrjyC8= 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=nI8FIjei; arc=none smtp.client-ip=209.85.218.46 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="nI8FIjei" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-b79e7112398so184741366b.3 for ; Tue, 06 Jan 2026 07:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1767714619; x=1768319419; 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=G9fgEx0U4KKIU9NUKf/BCizk5aPErtLpqSrpq7gCm0U=; b=nI8FIjei3O92+EJ41mbCUfElLwzG3HHKcK8uHCYKNr0384Bens4mwefIxVamgTxMNQ st4vS1S3IeqcM1fbdtRzsXt5SuxO8xLLDnYy1p0MzOWmnRabgk3jCslUqrnekHhTqOYP q4GMVJ8A82bFMuIUiHgZ+JGmtghbOnM+PiYXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767714619; x=1768319419; 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=G9fgEx0U4KKIU9NUKf/BCizk5aPErtLpqSrpq7gCm0U=; b=EkDhA8yonN/AdWU4M0ECr4vfHLqNqj5w2ShrSgSv1HkC7A7864k2sxZ7uGOnsY5gyb 31hhDBGgLjVOPnMbY+O/X/Zc0nA7K+WjIVQS+z2+3dO/YBIwuIAsra0cBCN+t3Axwj28 WpjKoy00WFkZLSbhY2jZYNGwD/O9nm5+IFHU+Q5+k/J7SGX1LyNDz5Mzl8uUtrMetHg3 7Z7hyrjKX2rTBhf1mulu//Bad14d3c9gyooqvqfb1tZXZl8r1cOErL+jye2HZdEyyiHs cIIW5szgw3mtrkyCXDqge6w+RKhhqJmy1HJzore9awOJRwEWL9jFrK0SFrTo8nTPnylx YyLg== X-Forwarded-Encrypted: i=1; AJvYcCUc5DD47dKY9oJ552JQ532efMMJBZBQF8/UPImCG13HSLl4z7166xFgVkT1LHqkTR+S7QMeMVTQMQJoCos=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4Lq5+Bta78qLbZzbhhKTCLiFI8OekLxfBmwjpt1gwQqVJY0No JaR0FHvxmn7MKA+UVmBJSIrTpmaEH4b2amCygRFfXKKIUz4YmiZYSibats60QdFbLg== X-Gm-Gg: AY/fxX7ZGQhdwKfKFLIA7GZCaJKl933Dj2Ykil0n4rzOc3NJ08RXwk6tVgyiww+LEkS eJ4LwE9BqJeRqitrnc3pHDrdO70nAmEPpa0OyNFioPmiQAMw/x62j5pHZ9uZJzDxYwQpbyKs5Yc sA+TT1nMyUTehLdqkr+odSs9oaR7010SwzNSkGKYLThlcsSBhwLlDrDnEZ3L5e4+fEYuPT3c9Wc MFFTg7GQAr7YnIl504MwVXCn7ep8CNCECIQlvY7YH45Dglc4rVBhe2s9lxR4rrBBvG12i9ydaDg +t+D+O6/CknWkjq4LbNYVtP+HozdboSjUWvB8MoBI2hwd3JDQk+/5kRJkWWTorkYmm2OQaf7pSm cXPtFUPt7dJhfdqQtdOZz/4JLSvpUp8DrXjxUHYUpS0MYy6wCVKubtuKfJgOr2uw0LAqF6QGaxD Z+3mz1qb0ApwnsWTQRzTcmNdsSSeA3Lg0= X-Google-Smtp-Source: AGHT+IH5ExdhH3cvp5++TTlavtYEe3AsTAcecnjP7jkcJzbJvxKDWz24P+rCoFWq2g2fHKYoI2gZmQ== X-Received: by 2002:a17:907:3c8e:b0:b79:f965:1ce1 with SMTP id a640c23a62f3a-b8426bedeb1mr362072666b.42.1767714619387; Tue, 06 Jan 2026 07:50:19 -0800 (PST) Received: from mitya-t14-2025 ([2a02:a31b:20c3:6680:43e9:5120:2208:3239]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a22ff58sm255887066b.6.2026.01.06.07.50.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 07:50:17 -0800 (PST) Date: Tue, 6 Jan 2026 16:50:11 +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> <20260106142301.GS125261@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: <20260106142301.GS125261@ziepe.ca> On Tue, Jan 06, 2026 at 10:23:01AM -0400, Jason Gunthorpe wrote: > On Tue, Jan 06, 2026 at 02:51:38PM +0100, Dmytro Maluka wrote: > > 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. > > You don't know what state the HW fetcher is in. This kind of race is possible: > > CPU FETCHER > read present = 1 > present = 0 > mangle qword 1 > read qword 1 > < fail - HW sees a corrupted entry > > > The flush is not just a flush but a barrier to synchronize with the HW > that it is done all fetches that may have been dependent on seeing > present = 1. > > So missing a flush after clearing present is possibly a bug today - I > don't remember what guarenteed the atomic size is for Intel IOMMU > though, if the atomic size is the whole entry it is OK since there is > only one fetcher read. Though AMD is 128 bits and ARM is 64 bits. Indeed, may be a bug... In the VT-d spec I don't immediately see a guarantee that context and PASID entries are fetched atomically. (And for PASID entries, which are 512 bits, that seems particularly unlikely.) > > 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? > > The HW doesn't read the values the CPU is writing, so it doesn't > matter if the compiler does something strange. That is the whole > justification for why it is possible to code it like this at all. > > The dma_mb() is also a compiler barrier and ensures all that > uncertainty is resolved. Once it completes a DMA from the HW will see > the program defined values only. The HW (the IOMMU) may read context / PASID / page table entries from memory at any time, whenever a device makes a DMA request so the IOMMU needs to translate it? We don't know if it happens before or after the barrier? So we'd better make sure that if it happens before the barrier (i.e. when the device is not supposed to do DMA), the compiler (and thus the CPU) doesn't set the present bit, so it stays non-present, so the IOMMU will block this unexpected/malicious DMA?