From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (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 E2ED230F950 for ; Tue, 20 Jan 2026 19:54:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768938873; cv=none; b=M+x5e4Boo8q6s7ERO7AbJMN/UWSJha9wXh4kaQ4th/4DHgExKQB77ZIbZiowNXc8wJ7l4/SB9h+ewP0VZW7XcOaz342ojpzAjsajKojpmBFAC0l/ZDoDQ1oiq4eDpumhIsNmLmj8a4GBGmaSnOLlVAEncsx53A81V0woky7wzww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768938873; c=relaxed/simple; bh=La0LsKkDKC8PbHNW+0fmemOwAXhZUMEOOr92W3Imo1A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ly+FA9B3NKZzxpfcav2F8VShx1hgAvYdV1wRK+wZVnPfJ6FkUSzudTkfgpwt1LWUEBqS2VMN8vrI7q7TtpjtGhjLPAcfinTmAXU5GNL2/Op8UmSjvY3VauPD6w0c9vcUQ88HKGAkYeEWYiEDI/0lB2NdcLKFEt+d4XEVK0W0330= 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=otLMBFh9; arc=none smtp.client-ip=209.85.222.181 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="otLMBFh9" Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-8c52c67f64cso606247085a.0 for ; Tue, 20 Jan 2026 11:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1768938870; x=1769543670; 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=fxUssvnFkASYj4oCeQRkWpfFPQUd3pm6yqx8I9NL0HI=; b=otLMBFh9wS4jNE/eOVB61YkXfwF2DtCZQ9oXbsT6vX1s5C8Ki6NHGdPlr2BYDcJ9RS zQuc2rHlrxcbgNN/secCjtqffJnb/nv9ubvPfz6XYuwbWT57fC5RiX2lQtXZa+WaWbQi JUgB7gtxSAIA0sakUAWlzxTq7cnHjHnmkTf9VZfH5l07WLdMMRVGxrYvtrY0EKJRYRed qVKY/NuHcz41sYNGTWeffTd/RHDw0gso57ntijsj5Mth885q6teQPLKbprERaDTJWVB9 S/HEN/FwJfcaPY/8Vx5BXmt8cBPXA6fU8CFuHoLnNJXiJ7y+73rPLGYSVoKtp7s0eDPS StxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768938870; x=1769543670; 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=fxUssvnFkASYj4oCeQRkWpfFPQUd3pm6yqx8I9NL0HI=; b=UV0+NDH2y/XWR5qguFffP4d7uXw0/CHA9nK/MXz1eJjpgL83MKaDfI46jqkoK96MdM xboEKImn2+rhHu6OJv0W45Kl8Yx/ZbEC2epbrTRHNimfGjxTuBtkk2WclVPBRWpY+SZH 1mEuA3RfmEmxajl5kS/mGKbdUPqp/j8oJE9azYhnTVwiRtrFQ6XcXkizYBen5uKFrsKQ Gte3BiIA6ZaHbgKhtZO8IqwkD6XZ1FaMQaaeo1srjiL+OakJD2q2/vFmiH8HUmGdSAGA /sFUlznOmxr983WFzHt6N+ojDCbHJgr5tli74Hbrc8HGm5nbIKfU2JnCNPmYP0DRUcs3 uj2g== X-Forwarded-Encrypted: i=1; AJvYcCXmsCF2JptOqw+vUGUSdhc0VAraIan0ki8r7ADfEQSE2McsspQty8iIJx/zwA/hvt2OnxDkhBo6X9Tg3SI=@vger.kernel.org X-Gm-Message-State: AOJu0YyjnX6HJ03Zt7EYj4xXWaqVmdjv97HldMVTmiEuJErxiRoAC0Au q3kMO5sVTqvp7boDETKZU65DA1APPT8gUJK1KAK2VmAEfM87tcwz12eqEWCv6BE7I8w= X-Gm-Gg: AY/fxX4qsAf7RxilTXJAindQmP0PsYHiSTpCTnZtYPEK5EG+d6IXVDfQN+lQNv/asr8 nOL85VVQcRs6Hwja8LC+9mD3WSIwKWa61rYAfAQBWYNAPDmGXE3ZWBpsAvhyYKyj/gYT0Twc1+Y s0RIAX9qxoX2Cn9c+5VM0bulWQLflfIalxdEfZ4cc57yuWhum7pYWCZT2piGF4tHhV1bK0QOmOX p/jbm5jeMJ4r6w9acuYMA68KGuld4UdIG7aOA/d9Zv3dr/j/tdvV1qsC8UObZ01i03iPzEjRxiF ub9A/Hop93lz8I+hViPbtA4CVKuh5JVONvHi8b2ZzXvh6Uhrd2MztWOXooWr4lFgsrPK9qe1tvM ih44XEYse2J5/5o5GRMkzsxYYlBagawwrIIdEdBh3OTf8rGCzWqfX1W0k6DFOE+tKuyHydPPkni B/6c970t3P83Vmb0xYx/B4axSW9/RR5jhKa9f5h9ZQHK/8+GuII6bc/IczO4OcrXcQpiw= X-Received: by 2002:a05:620a:40cd:b0:8c0:cbd8:20b0 with SMTP id af79cd13be357-8c6a6705321mr1981470385a.34.1768938869610; Tue, 20 Jan 2026 11:54:29 -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-8942e6ad0eesm109052086d6.32.2026.01.20.11.54.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 11:54:28 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1viHo4-00000005bZk-0dfl; Tue, 20 Jan 2026 15:54:28 -0400 Date: Tue, 20 Jan 2026 15:54:28 -0400 From: Jason Gunthorpe To: Robin Murphy Cc: Suzuki K Poulose , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-coco@lists.linux.dev, Catalin Marinas , will@kernel.org, steven.price@arm.com, Marek Szyprowski Subject: Re: [PATCH 1/2] dma-direct: Validate DMA mask against canonical DMA addresses Message-ID: <20260120195428.GW961572@ziepe.ca> References: <20260120064255.179425-1-aneesh.kumar@kernel.org> <2a0b6d1b-875a-4075-8fc9-a8534afc9168@arm.com> <0da8b73c-5bec-44c3-9902-221a11142c34@arm.com> <20260120151127.GP961572@ziepe.ca> <20260120175454.GA1325733@ziepe.ca> <2c04d4a7-559a-42d1-bc99-66e60d9f78c4@arm.com> 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: <2c04d4a7-559a-42d1-bc99-66e60d9f78c4@arm.com> On Tue, Jan 20, 2026 at 06:47:02PM +0000, Robin Murphy wrote: > > > then the fact is still that DA requires an SMMU for S2, so at worst > > > there should always be the possibility for an RMM to offer S1 SMMU > > > support to the Realm, we're just not there yet. > > > > Having a S1 would help a T=1 device, but it doesn't do anything for > > the T=0 devices. > > If we have an SMMU we have an SMMU - S1 for T=0 devices is just regular > VFIO/IOMMUFD in Non-Secure VA/IPA space, for which the VMM doesn't need the > RMM's help. I've long been taking it for granted that that one's a non-issue > ;) Well, sort of. Yes that's all true, but since the T=0 vSMMU cannot access private memory it will not work properly with the current driver in Linux which doesn't know how to allocate shared memory for the page table. > The only thing we can't easily handle (and would rather avoid) is S1 > translation for T=0 traffic from T=1 devices, since that would require the > Realm OS to comprehend the notion of a single device attached to two > different vSMMUs at once. Yes, so far the general consensus I've heard is that this will not be done, the vSMMU presented to the VM will only handle T=1 traffic and the OS must assume that T=0 traffic is identity. Given those two reasons my general take is that we will not see a T=0 vSMMU in ccVMs at all. > Rather, to be workable I think we'd need to keep the T=0 and T=1 > states described as distinct devices - which *could* then each be > associated with "shared" (VMM-provided) and "private" (RMM-provided) > vSMMU instances respectively - and leave it as the Realm driver's > problem if it wants to coordinate enabling and using both at the > same time, kinda like the link aggregation model. Hopefully we don't need to do this :( The current thought is that there would be only one device and when it is in T=0 mode the OS knows the linked iommu is not being used on ARM. IIRC AMD and Intel do not have this quirk. Sadly there are use cases for a TDISP device to do T=0 DMA before it reaches the run state. Jason