From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (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 21D3D273F9 for ; Tue, 6 Jan 2026 14:23:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767709385; cv=none; b=H9W9GPUrBpAs8RkZ34EUA12lzPIMxOczlvx4hsS0Bj9589kzJ9ER6UMV+mNVw0lMErXAmBLtyBiFSdBOBpj738NDDKdRAnIIdjgXSQMttX2cvMJDOnW/9Ovjy3DxxmajvIwaDrMA/vSzvNL3z7ED9zT8r/JHd18D2Zu0eyMmsx4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767709385; c=relaxed/simple; bh=D3hn8o8W41ASib38yz54W9zJegHoNaEKK0H0y7laV3k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JXWTr66Ob6kho8P/2SCfb8Mz87AY67gNXSWgE3HKqtjpSl5YItI1ae8NTpyU24nVeULTqUFtkZuC4LZID/NsZp/ng9Fk1xeokR0OPpPdmLGj1nn2b9i5s03/Dbyf02ASsN34yEjp4M1lIJavzXhFpbVGT6UVE29Hw2ApoTLUDaE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=bFZlHzu7; arc=none smtp.client-ip=209.85.219.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="bFZlHzu7" Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-88a367a1dbbso13531116d6.0 for ; Tue, 06 Jan 2026 06:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767709383; x=1768314183; 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=I0D3CvlFcm4pr/seu4ZgrWAYZBh6R3LQGn6S/koqnKc=; b=bFZlHzu7Qcmf9PNdEc5/dkWz45Sq4xzDTsmES9DESe2zFNDYY1GgJlq+pkYf2vnOIU zAp4kQU3V7kOR4CVLcmiFKZ4bxpJqACH5tuKxtlyyImpdJWcc/31TI/mtPl8lryt7/Qw k+cKqLFXWefmdKEIjy+h1nG4JGe3Rbseg95T/rdd6gKJ6bkRLe5wb/ArrvatodEt+0gy oKWSeB2Gp5R0hNUdstin8cRHY8/df/9Rg3GjWjOEr93OfMvRDMhYA/z0OLAB/gvTKpGI ucTVmD8oODRekIAWwZPKOia3DjfJzP1gH/mMMwh4RCvsp2smA26Y/PpmSMM/Xuk/R6UP UgSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767709383; x=1768314183; 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=I0D3CvlFcm4pr/seu4ZgrWAYZBh6R3LQGn6S/koqnKc=; b=snBa/hAVaJvzlEqmHhPGQTGi7Z6cCKJo9kCq43DD+chxY74BuNKoGkqN4r61oKcd4y TqAyB36JMwKrTBSiRkY9yvUpUTMoYhdcEPE7UPJi9AqlhwaNnDhysm4q2oULrOhb5eDW QNeD4AF1cyIXlmkC7xgv/fy6oRnrB9o3N+Mwt28nqLU8BHoB26+ev1jnR5BJAW6Buu4W f3NHihYJiBxJnO8H6ypufJoKegszPfujnz/qcEHvjKa882DZ/8SZ5BAGY2DolP8lvYtz rtB9dm8+ANmtQuHtcjJDz1yE0O7tIQ6SQt+Dy6gpqUaNDEExpbgmv3axh3nPO5hP26t7 bnaA== X-Forwarded-Encrypted: i=1; AJvYcCViMmUpcbUC0yOfTmzgJGHwCoHRiq5YG8Cuy40PTs+lYV+k9IA2xD5HODbshO/Vm7xOek8O+u//fKaZHgg=@vger.kernel.org X-Gm-Message-State: AOJu0YxRnobo1eTBwczO59MMJyNGdRzgw0YrZ3+AVdw/vmcCMtPnpnmq E62jqpEOt9M0LJHpQ6hi8AhJaNEclbZBfh1vsHEAZ2MCtvtLCBcmO57x/+9LAI36NjM= X-Gm-Gg: AY/fxX62Ne++HY0a9CgQlAPgculWqg0sDzuNS6EtrwsjSnmcFktRL8NvxqZctIuOlJH actEJwWMPn7g16hHm/3J4zbGpU2YoCoaeFNkR5tIHRRlBEiqZi348eWZ358v/cAQX4eFvtA+Pkg f0w9yqb7rLZ7SmtpOvsLmlMvs9uKacl6iEyA8C5Agf1Jx7sQIcKWrTLlpwwIzrsQ6+ZlZAxZjib 5Toc2WC2XDNSpE6eHbeCDRMtwABKW+jd9bU1xFVMB/xYSmxwlu1PGb3aAuFylRCeYk5WCQGJzwV Vkvm/yAC98IPlHGMc8rMs1bBecls5SlKyDfF7Mao2qGPagZcofEh7wqHS0tLGQakQxKw2qFCIjM tRmHQOwUBcNj3otN1Q1DwH8T61dVMnoNdO3LUxB8uiaeEoB/jW5gp1LR8AkwAbG0bHQcw2zAZ0V Vi68hj8ysiiGut4npcyYnWMKYXGbc1DAob9LDLCs77aobfNrBvP9gOpSRXKKQKCrCHVN8= X-Google-Smtp-Source: AGHT+IFzGRnnY+E+PXxkKzl3qVqNXYs8quD8xdQVu6fDbp50qflJwpcycz/Aa/6inYojSY9MRZgTJw== X-Received: by 2002:a05:6214:590f:b0:87b:f369:35d2 with SMTP id 6a1803df08f44-89075ebba0amr44896036d6.39.1767709383008; Tue, 06 Jan 2026 06:23:03 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-890772682besm14029016d6.50.2026.01.06.06.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 06:23:02 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vd7xd-00000001QS0-3KsY; Tue, 06 Jan 2026 10:23:01 -0400 Date: Tue, 6 Jan 2026 10:23:01 -0400 From: Jason Gunthorpe To: Dmytro Maluka 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: <20260106142301.GS125261@ziepe.ca> 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: On Tue, Jan 06, 2026 at 02:51:38PM +0100, Dmytro Maluka wrote: > > 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. It is already integrated into I showed it here for clarity. > 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. > 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. Jason