From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (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 67C0C206E7C for ; Fri, 8 Nov 2024 15:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731079541; cv=none; b=QRmrpb2TiwoGrwEO242nRibS86cTmy2y1JNu97kpeJoG5kaEflQ00B36O5cAOJWha8vF7+tHt+bpDs5FESepP2CqWEPKLefxXKJj1NnYZSDNejCY0LxGebIciaLzcJNuRoakMCKBdMJwNzujqVjwUSgK7d+nV44kmd1VzUZCmwM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731079541; c=relaxed/simple; bh=2feMVd+moXqEWqG7qu0YrJc0Jboh9RPoNC48SzdPbeI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tAAXTnS73/fctH1a9sYVX1bOZskptu6qDlUsPbpHxj0+qO66Z22iBfb7BzWnDMmPGYAQIixAF4qQ0bwYqGAC/aao1Jd4RBbyl2HhOPLWxUJXIBhoWYuLOT6xgeYd7CQ631LMnU5xe3ewPXkNRRv9bEMcS0RvTgpOAlsC6sgC5qQ= 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=bJY1kfzU; arc=none smtp.client-ip=209.85.222.173 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="bJY1kfzU" Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-7b155cca097so189713985a.1 for ; Fri, 08 Nov 2024 07:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1731079538; x=1731684338; 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=nbYXv3yCM9yQzCKa6ScUYgOxj5i+yJ5Ve18Z6DNxO2Y=; b=bJY1kfzUcarj5CrCE4Tih3DZkR2MPvb0tUrbaV67brM/zWFSSH4XDEINs+3lIpIn9G XOUMKNr+TXsHV43VcaUCVNsg5hkY7HaAjzisjsOFkPzkqf2wjChDM10bgh71BOaOrrfv Wf6a323Mkj68kqXlq68GFa2rqc+uNuFUgjNtHz9TLtkg/mwEQunzUDbDYQ4Y0v4vyRfK eYeQFHi1h45hnN0WM3KDpaY3MeBuVFFiuikvP0SCR8XP2sOmgPpOSFobXNSzQZP+uGtV N+NEaqh2K3YlIz3AKWeGCR7MPSMrKQ7XBJrkprKqy/9YgJoMrfrlr2YcXspzBqjS4ET4 QXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731079538; x=1731684338; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nbYXv3yCM9yQzCKa6ScUYgOxj5i+yJ5Ve18Z6DNxO2Y=; b=WH9HAC2HsDIFHA4m5l6HRZLYG72GHvS4/dVQqLzZ6RxLVO70GQHDacopuYUBc7CR5l eiT0tGY5Vle2yK3uZcqIniTYE+4agE+4pQjMo+5LLo/w06CK+3mlu0VAVdU9Xq1TA6h5 TDNh/3vOpJFUeAlDtArNk+8ngmngi0TCpI0F4U3DT9Y7StFkt2bQsC81l09fBRsjSWu6 QmG+3FddfZDvSM/dj3JTI/8EzgluKGYvVdXgSPZVQwo15IpQQfsDWvOLWUTthcg8kcwj Y3ZJ2qpKifzUnMeqObxDSSXZ3TGX9VQcSomAyhNI06dqHi+n3kKzZxRMA1mFYh9dVfWn KOvg== X-Forwarded-Encrypted: i=1; AJvYcCXw0uZ1cVKkSboqLSaokgNybemipuFdRJNXQV1oAawPOyCO1/zlPXcsJpzdWmIMVS+XLSVfOPLnn7bDusI=@vger.kernel.org X-Gm-Message-State: AOJu0Ywx3CctjOPCdYfxpMRfHLEmtRvQ7Is/M9BRutGpq2qpWYtxXSY6 fe59C9jR2JzIwiQnDblQcfj7Nuy5DKtCvN/s2mQTGK13Vj5zQrwIXhdicMODWKI= X-Google-Smtp-Source: AGHT+IH4eRArrUDZm2rUOb5KR+8EAvAFtyYH0Fr2uIHFPXrPpQnSMiiNxtBbq8LowDrIix/biyMB3w== X-Received: by 2002:a05:620a:4049:b0:7b1:4cc0:5e32 with SMTP id af79cd13be357-7b3328aeb7dmr490547585a.9.1731079538361; Fri, 08 Nov 2024 07:25:38 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-128-5.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.128.5]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b32ac51659sm170158385a.42.2024.11.08.07.25.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Nov 2024 07:25:37 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1t9Qrh-00000002Zza-1RVx; Fri, 08 Nov 2024 11:25:37 -0400 Date: Fri, 8 Nov 2024 11:25:37 -0400 From: Jason Gunthorpe To: Christoph Hellwig Cc: Robin Murphy , Leon Romanovsky , Jens Axboe , Joerg Roedel , Will Deacon , Sagi Grimberg , Keith Busch , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Andrew Morton , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, matthew.brost@intel.com, Thomas.Hellstrom@linux.intel.com, brian.welty@intel.com, himal.prasad.ghimiray@intel.com, krishnaiah.bommu@intel.com, niranjana.vishwanathapura@intel.com Subject: Re: [PATCH v1 00/17] Provide a new two step DMA mapping API Message-ID: <20241108152537.GN35848@ziepe.ca> References: <3567312e-5942-4037-93dc-587f25f0778c@arm.com> <20241104095831.GA28751@lst.de> <20241105195357.GI35848@ziepe.ca> <20241107083256.GA9071@lst.de> <20241107132808.GK35848@ziepe.ca> <20241107135025.GA14996@lst.de> <20241108150226.GM35848@ziepe.ca> <20241108150500.GA10102@lst.de> 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: <20241108150500.GA10102@lst.de> On Fri, Nov 08, 2024 at 04:05:00PM +0100, Christoph Hellwig wrote: > On Fri, Nov 08, 2024 at 11:02:26AM -0400, Jason Gunthorpe wrote: > > It is fully OK? Can't dma_map_page() trigger swiotlb? It must not do > > that for P2P. How does it know the difference if it just gets a phys? > > dma_direct_map_page checks for p2p pages in the swiotlb bounce > path already in the current kernel, and dma_map_sg relies on exactly > that check to prevent bouncing for p2p. I'm asking how it will work if you change the struct page argument to physical, because today dma_direct_map_page() has: if (is_pci_p2pdma_page(page)) return DMA_MAPPING_ERROR; Which is exactly the sorts of things I'm looking at when when I say to get rid of struct page. What I'm thinking about is replacing code like the above with something like: if (p2p_provider) return DMA_MAPPING_ERROR; And the caller is the one that would have done is_pci_p2pdma_page() and either passes p2p_provider=NULL or page->pgmap->p2p_provider. Anyhow, I hope Leon will attempt this once this is settled and it will make more sense in patches. I'm just brainstorming how I've been thinking of it. Another option would be some 'is_pci_p2pdma_page_phys(phys)', but I think that is going to be worse performance than managing a p2p_provider pointer in the mapping call chain explicitly. Jason