From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1EC63CEFC39 for ; Tue, 8 Oct 2024 17:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8oNTWGsjtAu+USpdmvJ90wsueiHpej3knh3aneDagUw=; b=aEsVaN/LId7Ye9TEn5+xzTs065 NwHVVghFTpKDioLLv8EiWzH/uwazhyW4kJxfEQL79OWDQPuBeksoWQllrdLp9Epbxvdq9QGFpYrBe Hfua5/iyAcIOUbIQ3TVZ+lmm+WkgTOsiComCNCCH5yYG0wG9VaYNz6CLgjudoQPF5rP0HX3h6Cy+E aN5tzQHmRMFgiBfEtFqeSvL0cDHgn/62YYwpe4IIUBl4yo3cTBTSbsQsch0b2vKYoeaJPAO/xcGyt WpLLJWGxInQT/lSqPrUOtW2a2NYwMqFLnMn1YZ3vaYbKYmj4VDfHOdtaWeMPQbjcSr+fi1QNfXgwV BZpZnR3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1syEMt-00000006iJn-1kxo; Tue, 08 Oct 2024 17:51:31 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1syEDn-00000006gG5-0kHA for linux-arm-kernel@lists.infradead.org; Tue, 08 Oct 2024 17:42:08 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 52D955C5CCF; Tue, 8 Oct 2024 17:42:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5DA0C4CECE; Tue, 8 Oct 2024 17:42:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728409326; bh=eNUS50KcHF91ZvltzMFX+z0qLcRzb93tuIxwqHyfZpU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RgMhxGZqsRMqT4paQFe4UnOpNo4+bdRdiHLVDYBcHzRLR/O2gLnNDAJYM21iT1Pqd XIL2Ab3hIPmZon4pTVVs5CemIRJUd9Rx06YvJmFJMb6Zx9PP0oVZmCw/gQfXqzDt2A Zg+6T4DjbXXILdcZsIx+fbG2hB5uPDtCRzFEULjRuwwzsRcR5xVSJBCh7hJQe/OtMs k9Nft7nq4p8xA+nSeUIb+wpVTzCmgxQuh+gxZhA0kyVzEoIFy1Uf1IZbGkyLSkm7x4 AwjfOuhpmGVZD4Fg03JxeJe3nGPOG7vuhaRH/4Dx6wXXaRM0IqkPyLmuUNWP3+4/hr f1dDdFYwxBtzQ== Date: Tue, 8 Oct 2024 18:42:01 +0100 From: Will Deacon To: Jason Gunthorpe Cc: Yang Shi , nicolinc@nvidia.com, james.morse@arm.com, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [v3 PATCH] iommu/arm-smmu-v3: Fix L1 stream table index calculation for 32-bit sid size Message-ID: <20241008174201.GB11091@willie-the-truck> References: <20241004180405.555194-1-yang@os.amperecomputing.com> <20241008133458.GA10474@willie-the-truck> <20241008151506.GC762027@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241008151506.GC762027@ziepe.ca> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241008_104207_288472_3A73494F X-CRM114-Status: GOOD ( 17.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 08, 2024 at 12:15:06PM -0300, Jason Gunthorpe wrote: > On Tue, Oct 08, 2024 at 02:34:58PM +0100, Will Deacon wrote: > > > This all looks a bit messy to me. The architecture guarantees that > > 2-level stream tables are supported once we hit 7-bit SIDs and, although > > the driver relaxes this to > 8-bit SIDs, we'll never run into overflow > > problems in the linear table code above. > > My original point was about the confidential compute position (sigh) > that the untrusted hypverisor should not corrupt the driver. > > So your statement is architecturally true, but we never check that > IDR0_ST_LVL_2LVL is set if IDR1_SIDSIZE > 2**7, and so we can get into > this situation where the hypervisor could trigger some kind of bad > behavior. > > > So I'm inclined to take Daniel's one-liner [1] which just chucks the > > 'ULL' suffix into the 2-level case. Otherwise, we're in a weird > > I think you should take it and let better be for the CC crowd. Heh. I wish them luck! :p Will