From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv2-f42.google.com (mail-qv2-f42.google.com [74.125.230.170]) (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 4D1553537C4 for ; Mon, 28 Sep 2026 17:29:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.230.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790616583; cv=none; b=CBd9SDUduEQlfSvD60KTDB5e+dckAofqcRxUADSLHd6wvOYzThgo1gN2urRVKbgiRU79AY8kkk+Iof/axRrKxzqzPa/XjYYAFx9Fq0RU2RiwQjHx2EOypvOH0CoTtNy2ajZc4aj/CWN3kV/H2xcdvsMoOrSWCNhVqUzqfRnUYVE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790616583; c=relaxed/simple; bh=SKQB0mEZagqmGsDNZPnaWe7gUble3NHrhIKbwNSH1Jw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YoeXCtkSLscwerYPDGq3F3GTJzNIne1wzqJ1jEoNbrdOABd8Rlkw15pw1bzV/iDqbl84Mjnfgcm35BHHR09xaB/QiSx1dJH/FzT0haAiffnPh7RRz6ckK65toqlWxw5kiS3HfCzEeaIyF92QwUWAqdT6kzC5CMq1hn0OxXMSUFY= 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=AXmJdboN; arc=none smtp.client-ip=74.125.230.170 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="AXmJdboN" Received: by mail-qv2-f42.google.com with SMTP id 6a1803df08f44-9143e192df5so24932606d6.3 for ; Mon, 28 Sep 2026 10:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1790616581; x=1791221381; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=F8wHi2lHLlVmnngzxn3a4naORn9qZPczzGL0TvCk5Do=; b=AXmJdboNcWfKQqwuUPCXX6Rn93Y/ElzgHMYokUjabBvqd2Xqe8xSV+pwcD0LXzNZW2 8viM3Ku+mp73QMATFvmcekMooi2y7DURd7K97gX6ogo9XH/0i80JoLcUwLr14lwGgje2 uXVL+jaLV2cPhsmHFcgkWM1+NQflhZkSRUkCpfI6fR8UBC5ZOrsLx/3Zp6rgE+ZXQW+v YZZAFTIec7nOUhTYT0SSMxVudqvgh/VKoBxSo48Ry8BMg9KgFWpnIKlEW+yJW/Db4J5B fSF7H1/lLqMh9MrlEVrvnSqWdih01PAd0RdYO/AaK8rLLHEvulSG7LoKrZ/8QZ6sCiln 1a5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790616581; x=1791221381; h=in-reply-to:content-transfer-encoding:content-disposition :content-type: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:content-type; bh=F8wHi2lHLlVmnngzxn3a4naORn9qZPczzGL0TvCk5Do=; b=pdfTpjyvuUR4QwWivOIBsqTyBIRMb0vK/0YislyjmaARXsDKZRkZXfTnw2HbVhBPIV DwcdAXza5ezSJxjpAWiJ+ugXm0F74n6Df9p8OImVLMjQNwJK1IGZAOICC2149bikVGN3 o/ZcWxrLBPdeGfVrUZZl7NEFU94zWKUzjhF5OfW9nN++5zeOKhvOOR7TYXm4EEAtem10 JNdS9Pf0tCdG40e9UpxZ6JLwKx/3foWeJeENic0L+xPlGIezIep/uIwoah6yZyCHUzoP Ut3tk43c5SZUfhS9CTv841zOFM4e99nkt7oZSZlerjm1QlKzgkFyvMmDcVu5Dq6rIFj4 D8Eg== X-Forwarded-Encrypted: i=1; AKwUvBwDkmUtmYgTq5XQNkMKWOphzf1zV9CBYMxlhf6dizcvLSGClHe/65P/c50RhBetlBG7OtI0krgJC7Y=@vger.kernel.org X-Gm-Message-State: AFuF++mSsBlCNU0SGh8mEoyzspzYsUHLW40YhLaAdnrlOfD9OBV/+bYX bux98hzYZsnfW9q4hbrwE36Wcmef/RLPM6Jo7oYuK9/tq/QUeFyyb60vWkyALtQ0dYg= X-Gm-Gg: AYBFou1YgMZdyvTsKweI7XaXapCXKU9qnZnlqfc5lSfNMwdpUR7mSMhNQBobbwOfl9L XlvIiWqSiFTcl7AM0kc3OugtuH9Pu6rGorj+h5/k9yx2LjYRzUW+K2rc/bbZoCXk7zplAVIaP2j 6MKJOJyoNRn+qh+khucZOhfmjZkMSTYX2LilCJD1CjbO8TkhrLJX6/Wc5ZfB/9q7B9iR2osGxWf AZCDnBt8MDTQ+lIcygC/Xr2zhtzFJbIAZsxxQYoIb1I0cpl1UwYIYk/N2NX1kBPBXKc8mht8Gwf bUIDiBsuL8RCd2wl2IwBp4+qOCSPZ9hBsUk1/9x20++v48SyOB3s4z3msSqjCIQiQXT43T8nSdn upBI4YiU71+0LT6OPFRC0vB3vrgK/+Fb6TCu7ey74XPNml/Ia4VpN4jrbEjEh0uR1PVX2/kkFph cR1Dz6n+NFnkzv1MnpmegM8bbkuEO7oIYsB8e+R5f9Aoea X-Received: by 2002:a05:6214:19c6:b0:916:7629:f1c with SMTP id 6a1803df08f44-91676291098mr52487856d6.10.1790616581176; Mon, 28 Sep 2026 10:29:41 -0700 (PDT) Received: from ziepe.ca ([130.41.10.202]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91430df77adsm84361036d6.26.2026.09.28.10.29.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2026 10:29:40 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1xBFAZ-00000007NhG-43XU; Mon, 28 Sep 2026 14:29:39 -0300 Date: Mon, 28 Sep 2026 14:29:39 -0300 From: Jason Gunthorpe To: Zhiping Zhang Cc: fengchengwen , Leon Romanovsky , Michael Guralnik , Sumit Semwal , Christian Konig , Alex Williamson , Bjorn Helgaas , kvm@vger.kernel.org, linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v13 5/5] RDMA/mlx5: get tph for p2p access when registering dma-buf mr Message-ID: <20260928172939.GK163130@ziepe.ca> References: <20260731211601.3033906-1-zhipingz@meta.com> <20260731211601.3033906-6-zhipingz@meta.com> <20260924233058.GA163130@ziepe.ca> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Sep 24, 2026 at 11:17:57PM -0700, Zhiping Zhang wrote: > On Thu, Sep 24, 2026 at 4:31 PM Jason Gunthorpe wrote: > > > > > > > On Wed, Sep 23, 2026 at 11:24:56PM -0700, Zhiping Zhang wrote: > > > I don't think this belongs in the importer. Every in-tree dma-buf > > > caller of pci_p2pdma_distance() is the exporter, in its .attach, > > > clearing attach->peer2peer -- amdgpu_dma_buf.c, xe_dma_buf.c, > > > habanalabs memory.c. There is no importer-side caller. > > > > Right, and they shouldn't be doing that, but it still has to be > > checked that the st is going directly to the peer device not the host > > bridge. Not using the distance, but by the PCI_P2PDMA_MAP_BUS_ADDR > > indication. > > > > I fear you will need some of Leon's series to make that happen. > > > > So probably the proposed change to dmabuf ops is far too simple. > > > > Jason > > Hi Jason, > > Thanks for the comments. > > Agreed -- the tag should not be handed out unless the routing is > PCI_P2PDMA_MAP_BUS_ADDR. That can be enforced conservatively on 7.3 > with two changes. I can fold both into patch 4. > ``` > In drivers/pci/p2pdma.c, make pci_p2pdma_map_type() callable from > tristate VFIO_PCI_CORE: > > EXPORT_SYMBOL_GPL(pci_p2pdma_map_type); No, that's been rejected several times already. > and in drivers/vfio/pci/vfio_pci_dmabuf.c, > vfio_pci_dma_buf_get_pci_tph() gains: > > struct dma_buf_attachment *attach; > > if (list_empty(&dmabuf->attachments)) > return -EOPNOTSUPP; > > list_for_each_entry(attach, &dmabuf->attachments, node) > if (pci_p2pdma_map_type(priv->provider, attach->dev) != > PCI_P2PDMA_MAP_BUS_ADDR) > return -EOPNOTSUPP; > ``` Also no, this has to be done via PCI_P2PDMA_MAP_BUS_ADDR which also enforces putting the determination in the right place in the code flow.. > Two properties are worth stating explicitly: Ah! AI! Jason