From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.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 1EC47390991 for ; Tue, 3 Mar 2026 00:19:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772497155; cv=none; b=hDAMpcWiaXUikJIk7/PQGJf6pxftYdGyLyyioD7ScNOf6MlqikxWvcL0lwM6e60hO6ChA/IIwMLhlcewg06QIm8aVniZyJJ4zO6bfLPmRw9uCJltrRYHX4zGFYL8pg1ObqEL/Fjp+03Q3BjsPO0o5YTQjT6bSyvsUApo2wWyb9o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772497155; c=relaxed/simple; bh=pt/lyo6zfzp5um0atVczBnFUoiSRW5zCwV7Y9opM2zA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qhmF+hpuL+sD3rgG1h+xbhL9crLSZ4d2PuGvDWOkJXex0pCrd+CPczfdCn8Dtt+VsRNCarjc3cavC6+ycUM6FR/VDEMf8H5TrDaKeLgMvaRgTmex43BpdwYWk//MQVc2Q6oMtjyQpQ5e2whkLSnZnLNRkuFlQs3wldNKLGkeDZ8= 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=eFN5gBbE; arc=none smtp.client-ip=209.85.160.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="eFN5gBbE" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-5069df1de6fso43450471cf.3 for ; Mon, 02 Mar 2026 16:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1772497153; x=1773101953; 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=uBmRMf9aoSKjaEvUH8kwvq+kwq2UPw7m0MsTmit1ZFs=; b=eFN5gBbErwVOTtyKEbm2+UHQMiJjY6+8B3n9VqHgozuGH4ST2aWdm3VXsDrkV5U7J4 NZFuSyOGBAxZtmyzog6VfIYKLdTgaA3JY+jlK3fQR37PbFAmBsWvqAh3WHkbxGWgIBpQ c5EKTl43lE3tYaAbKx6YGNlTMmAvQXX+zCqFDkafQhgNitlrSlEBcagkJvJ8nfhvCGZq SQPFXS0/IvalVkGRbwY5hvEeoEwxtmD2kk8kF/2CQ77N92otWVJKn8gxGq0mlfcvsata xIOBF6bjvmNzgrqScf7zx6Q7Rh53V0U3fdf+hy6Ju9ze1Iynt+7jT3kGJ2kSAh92gOCZ cdyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772497153; x=1773101953; 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=uBmRMf9aoSKjaEvUH8kwvq+kwq2UPw7m0MsTmit1ZFs=; b=EQ+ch0joazZSoqgqfYxsXyYo9AMBcLysiggkv8jmDtfwFu81VpBPlHeH66i4uG9eO6 EWPvd7Yd6/wCFwfUc9CopLc/v9otibsKEopXGxE8VvjkRsTPTUUB9oGF82Vyq5uZG4e9 fazvUpYndfRFgzyuUTWi6UVTdehwiNuIb/OeDAv4X9Emo9PPHpdtY34N+2r7A/lXiCJk umpyEYyiF1h3/J4dykD4WFK7t2RtGFT00XEa2cARwiKh00FdE5W+a02obuBCNWGTTozS Oa05LJWTR3tQUdrXm3YqfGwJ1FpImHVAZZOWaf8r1AT8JdEyRrDZZ7VxG81wCfUABHF4 Nf5w== X-Forwarded-Encrypted: i=1; AJvYcCVwUHI0XSzD9jqtHT/ts9X2BEPTCRmx1ImU1n1x6AjcJCaoOIGlXcd5Y+TsD+QyWT+zJdkFQ1sHgsp/JMk=@vger.kernel.org X-Gm-Message-State: AOJu0YzQfiTNtf9791QS+5EZIfXbIIQWzuE353ZWsc2rN0GRL+xE560K UcWa80kfjs9q4GMLVEhobzaCX0wjZXeGp6f9/SjPn19a3fonV8aLFZ4zo4ZdxaZLeVE= X-Gm-Gg: ATEYQzzxzmMkrezR8nY3zV6XEMN1vpfg3QFDI90MukYr4x2W9OlOlwZ94MmAnO9Wwit X5wCXxp+5dDWi+nSPH34UhRNfB9T2lQn4agisjOU5S0pzX+3k4EZAdypcElEtMvM7cEOfIzIF4N T0OOFBduI/cWj58gzRyLzHOUY51m+ogk3ScrRh/Pc/OIiasumsJrrssd9ERsguI8sOIb0f8tml4 ukINEthmXGlrKH6fMYrHb1zAt/RSQmHT77DNlNShMtuXvGGL1k5WgdtZo0xtNHQHikPKydsYP9h 5knFDac6ZWf+Xx9ikenHPPxeVVN+lsG5UsnHkU3ssX+fqJ17akAw9hS0jrcw0ljEIhYoo8tr9WE bos92sm5FeW6sQtCQiv1ZeAC3PPZtHywAiN96+gxMqRcp3kJWzbdKOFy4oCGiF2r/+YPjazEggk LH7eza92NdlqmKELaIppbB8NRGPo/+zmJJR6/1gOgUZJvj6g+PV2SJP3eLZAWihCV8+bhyr+HDe dbZ6Uzc X-Received: by 2002:a05:622a:1ba5:b0:4ff:c8ae:efe4 with SMTP id d75a77b69052e-507527824e3mr187758101cf.30.1772497152911; Mon, 02 Mar 2026 16:19:12 -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-899c7159b44sm115519746d6.9.2026.03.02.16.19.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2026 16:19:12 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vxDTj-000000042qC-2Ytm; Mon, 02 Mar 2026 20:19:11 -0400 Date: Mon, 2 Mar 2026 20:19:11 -0400 From: Jason Gunthorpe To: dan.j.williams@intel.com Cc: Robin Murphy , Alexey Kardashevskiy , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Bjorn Helgaas , Marek Szyprowski , Andrew Morton , Catalin Marinas , Michael Ellerman , Mike Rapoport , Tom Lendacky , Ard Biesheuvel , Neeraj Upadhyay , Ashish Kalra , Stefano Garzarella , Melody Wang , Seongman Lee , Joerg Roedel , Nikunj A Dadhania , Michael Roth , Suravee Suthikulpanit , Andi Kleen , Kuppuswamy Sathyanarayanan , Tony Luck , David Woodhouse , Greg Kroah-Hartman , Denis Efremov , Geliang Tang , Piotr Gregor , "Michael S. Tsirkin" , Alex Williamson , Arnd Bergmann , Jesse Barnes , Jacob Pan , Yinghai Lu , Kevin Brodsky , Jonathan Cameron , "Aneesh Kumar K.V (Arm)" , Xu Yilun , Herbert Xu , Kim Phillips , Konrad Rzeszutek Wilk , Stefano Stabellini , Claire Chang , linux-coco@lists.linux.dev, iommu@lists.linux.dev Subject: Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices Message-ID: <20260303001911.GA964116@ziepe.ca> References: <20260225053806.3311234-1-aik@amd.com> <20260225053806.3311234-5-aik@amd.com> <699f238873ae7_1cc5100b6@dwillia2-mobl4.notmuch> <04b06a53-769c-44f1-a157-34591b9f8439@arm.com> <699f621daab02_2f4a1008f@dwillia2-mobl4.notmuch> <20260228002808.GO44359@ziepe.ca> <69a622e92cccf_6423c10092@dwillia2-mobl4.notmuch> 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: <69a622e92cccf_6423c10092@dwillia2-mobl4.notmuch> On Mon, Mar 02, 2026 at 03:53:13PM -0800, dan.j.williams@intel.com wrote: > > > The specification allows it, but Linux DMA mapping core is not yet ready > > > for it. So the expectation to start is that the device loses access to > > > its original shared IOMMU mappings when converted to private operation. > > > > Yes, the underlying translation changes, but no, it doesn't loose DMA > > access to any shared pages, it just goes through the T=1 IOMMU now. > > Yes, what I meant to say is that Linux may need to be prepared for > implementations that do not copy over the shared mappings. At least for > early staging / minimum viable implementation for first merge. > > > The T=1 IOMMU will still have them mapped on all three platforms > > AFAIK. > > Oh, I thought SEV-TIO had trouble with this, if this is indeed the case, > great, ignore my first comment. Alexey? I think it is really important that shared mappings continue to be reachable by TDISP device. > I have a v2 of a TEE I/O set going out shortly and sounds like it will > need a rethink for this attribute proposal for v3. I think it still helps to > have combo sets at this stage so the whole lifecycle is visible in one > set, but it is nearly at the point of being too big a set to consider in > one sitting. My problem is I can't get in one place an actually correct picture of how the IOVA translation works in all the arches and how the phys_addr_t works. So it is hard to make sense of all these proposals. What I would love to see is one series that deals with this: [PATCH v2 11/19] x86, dma: Allow accepted devices to map private memory For *all* the arches, along with a description for each of: * how their phys_addr_t is constructed * how their S2 IOMMU mapping works * how a vIOMMU S1 would change any of the above. Then maybe we can see if we are actually doing it properly or not. > > ARM has a "solution" right now. The location of the high bit is > > controlled by the VMM and the VMM cannot create a CC VM where the IPA > > space exceeds the dma_mask of any assigned device. > > > > Thus the VMM must limit the total available DRAM to fit within the HW > > restrictions. > > > > Hopefully TDX can do the same. > > TDX does not have the same problem, but the ARM "solution" seems > reasonable for now. I'm surprised because Xu said: This is same as Intel TDX, the GPA shared bit are used by IOMMU to target shared/private. You can imagine for T=1, there are 2 IOPTs, or 1 IOPT with all private at lower address & all shared at higher address. https://lore.kernel.org/all/aaF6HD2gfe%2Fudl%2Fx@yilunxu-OptiPlex-7050/ So how come that not have exactly the same problem as ARM? Jason