From: Jerome Glisse <jglisse@redhat.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Joerg Roedel <jroedel@suse.de>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Felix Kuehling <Felix.Kuehling@amd.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Christoph Hellwig <hch@lst.de>,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
Jason Gunthorpe <jgg@mellanox.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Robin Murphy <robin.murphy@arm.com>,
Christian Koenig <christian.koenig@amd.com>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
Date: Tue, 29 Jan 2019 16:00:08 -0500 [thread overview]
Message-ID: <20190129210007.GO3176@redhat.com> (raw)
In-Reply-To: <8b4e0157-4eaf-c79a-28d0-7a266abe2207@deltatee.com>
On Tue, Jan 29, 2019 at 01:44:09PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:44 p.m., Greg Kroah-Hartman wrote:
> > On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-29 10:47 a.m., jglisse@redhat.com wrote:
> >>> +bool pci_test_p2p(struct device *devA, struct device *devB)
> >>> +{
> >>> + struct pci_dev *pciA, *pciB;
> >>> + bool ret;
> >>> + int tmp;
> >>> +
> >>> + /*
> >>> + * For now we only support PCIE peer to peer but other inter-connect
> >>> + * can be added.
> >>> + */
> >>> + pciA = find_parent_pci_dev(devA);
> >>> + pciB = find_parent_pci_dev(devB);
> >>> + if (pciA == NULL || pciB == NULL) {
> >>> + ret = false;
> >>> + goto out;
> >>> + }
> >>> +
> >>> + tmp = upstream_bridge_distance(pciA, pciB, NULL);
> >>> + ret = tmp < 0 ? false : true;
> >>> +
> >>> +out:
> >>> + pci_dev_put(pciB);
> >>> + pci_dev_put(pciA);
> >>> + return false;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(pci_test_p2p);
> >>
> >> This function only ever returns false....
> >
> > I guess it was nevr actually tested :(
> >
> > I feel really worried about passing random 'struct device' pointers into
> > the PCI layer. Are we _sure_ it can handle this properly?
>
> Yes, there are a couple of pci_p2pdma functions that take struct devices
> directly simply because it's way more convenient for the caller. That's
> what find_parent_pci_dev() takes care of (it returns false if the device
> is not a PCI device). Whether that's appropriate here is hard to say
> seeing we haven't seen any caller code.
Caller code as a reference (i already given that link in other part of
thread but just so that people don't have to follow all branches).
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-p2p&id=401a567696eafb1d4faf7054ab0d7c3a16a5ef06
Cheers,
Jérôme
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Rafael J . Wysocki" <rafael@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Christian Koenig <christian.koenig@amd.com>,
Felix Kuehling <Felix.Kuehling@amd.com>,
Jason Gunthorpe <jgg@mellanox.com>,
linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org,
Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <jroedel@suse.de>,
iommu@lists.linux-foundation.org
Subject: Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
Date: Tue, 29 Jan 2019 16:00:08 -0500 [thread overview]
Message-ID: <20190129210007.GO3176@redhat.com> (raw)
In-Reply-To: <8b4e0157-4eaf-c79a-28d0-7a266abe2207@deltatee.com>
On Tue, Jan 29, 2019 at 01:44:09PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:44 p.m., Greg Kroah-Hartman wrote:
> > On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-29 10:47 a.m., jglisse@redhat.com wrote:
> >>> +bool pci_test_p2p(struct device *devA, struct device *devB)
> >>> +{
> >>> + struct pci_dev *pciA, *pciB;
> >>> + bool ret;
> >>> + int tmp;
> >>> +
> >>> + /*
> >>> + * For now we only support PCIE peer to peer but other inter-connect
> >>> + * can be added.
> >>> + */
> >>> + pciA = find_parent_pci_dev(devA);
> >>> + pciB = find_parent_pci_dev(devB);
> >>> + if (pciA == NULL || pciB == NULL) {
> >>> + ret = false;
> >>> + goto out;
> >>> + }
> >>> +
> >>> + tmp = upstream_bridge_distance(pciA, pciB, NULL);
> >>> + ret = tmp < 0 ? false : true;
> >>> +
> >>> +out:
> >>> + pci_dev_put(pciB);
> >>> + pci_dev_put(pciA);
> >>> + return false;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(pci_test_p2p);
> >>
> >> This function only ever returns false....
> >
> > I guess it was nevr actually tested :(
> >
> > I feel really worried about passing random 'struct device' pointers into
> > the PCI layer. Are we _sure_ it can handle this properly?
>
> Yes, there are a couple of pci_p2pdma functions that take struct devices
> directly simply because it's way more convenient for the caller. That's
> what find_parent_pci_dev() takes care of (it returns false if the device
> is not a PCI device). Whether that's appropriate here is hard to say
> seeing we haven't seen any caller code.
Caller code as a reference (i already given that link in other part of
thread but just so that people don't have to follow all branches).
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-p2p&id=401a567696eafb1d4faf7054ab0d7c3a16a5ef06
Cheers,
Jérôme
next prev parent reply other threads:[~2019-01-29 21:00 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 17:47 [RFC PATCH 0/5] Device peer to peer (p2p) through vma jglisse
2019-01-29 17:47 ` jglisse
2019-01-29 17:47 ` [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability jglisse
2019-01-29 18:24 ` Logan Gunthorpe
2019-01-29 19:44 ` Greg Kroah-Hartman
2019-01-29 19:44 ` Greg Kroah-Hartman
2019-01-29 19:53 ` Jerome Glisse
2019-01-29 20:44 ` Logan Gunthorpe
2019-01-29 21:00 ` Jerome Glisse [this message]
2019-01-29 21:00 ` Jerome Glisse
2019-01-29 19:56 ` Alex Deucher
2019-01-29 19:56 ` Alex Deucher
2019-01-29 20:00 ` Jerome Glisse
2019-01-29 20:24 ` Logan Gunthorpe
2019-01-29 21:28 ` Alex Deucher
2019-01-30 10:25 ` Christian König
2019-01-29 17:47 ` [RFC PATCH 2/5] drivers/base: " jglisse
2019-01-29 18:26 ` Logan Gunthorpe
2019-01-29 19:54 ` Jerome Glisse
2019-01-29 19:46 ` Greg Kroah-Hartman
2019-01-29 19:56 ` Jerome Glisse
2019-01-29 17:47 ` [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma jglisse
2019-01-29 18:36 ` Logan Gunthorpe
2019-01-29 19:11 ` Jerome Glisse
2019-01-29 19:24 ` Logan Gunthorpe
2019-01-29 19:44 ` Jerome Glisse
2019-01-29 20:43 ` Logan Gunthorpe
2019-01-30 7:52 ` Christoph Hellwig
2019-01-29 19:32 ` Jason Gunthorpe
2019-01-29 19:50 ` Jerome Glisse
2019-01-29 20:24 ` Jason Gunthorpe
2019-01-29 20:44 ` Jerome Glisse
2019-01-29 20:44 ` Jerome Glisse
2019-01-29 23:02 ` Jason Gunthorpe
2019-01-30 0:08 ` Jerome Glisse
2019-01-30 0:08 ` Jerome Glisse
2019-01-30 4:30 ` Jason Gunthorpe
2019-01-30 15:43 ` Jerome Glisse
2019-01-29 20:39 ` Logan Gunthorpe
2019-01-29 20:57 ` Jerome Glisse
2019-01-29 21:30 ` Logan Gunthorpe
2019-01-29 21:50 ` Jerome Glisse
2019-01-29 21:50 ` Jerome Glisse
2019-01-29 22:58 ` Logan Gunthorpe
2019-01-29 23:47 ` Jerome Glisse
2019-01-30 1:17 ` Logan Gunthorpe
2019-01-30 2:48 ` Jerome Glisse
2019-01-30 4:18 ` Jason Gunthorpe
2019-01-30 8:00 ` Christoph Hellwig
2019-01-30 15:49 ` Jerome Glisse
2019-01-30 19:06 ` Jason Gunthorpe
[not found] ` <20190130190651.GC17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 19:45 ` Logan Gunthorpe
2019-01-30 19:45 ` Logan Gunthorpe
[not found] ` <840256f8-0714-5d7d-e5f5-c96aec5c2c05-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-01-30 19:59 ` Jason Gunthorpe
2019-01-30 19:59 ` Jason Gunthorpe
[not found] ` <20190130195900.GG17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 21:01 ` Logan Gunthorpe
2019-01-30 21:01 ` Logan Gunthorpe
[not found] ` <35bad6d5-c06b-f2a3-08e6-2ed0197c8691-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-01-30 21:50 ` Jason Gunthorpe
2019-01-30 21:50 ` Jason Gunthorpe
[not found] ` <20190130215019.GL17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 22:52 ` Logan Gunthorpe
2019-01-30 22:52 ` Logan Gunthorpe
2019-01-30 23:30 ` Jason Gunthorpe
2019-01-31 8:13 ` Christoph Hellwig
2019-01-31 15:37 ` Jerome Glisse
2019-01-31 19:02 ` Jason Gunthorpe
2019-01-31 19:19 ` Logan Gunthorpe
2019-01-31 19:54 ` Jason Gunthorpe
2019-01-31 19:35 ` Jerome Glisse
2019-01-31 19:44 ` Logan Gunthorpe
2019-01-31 19:58 ` Jason Gunthorpe
2019-01-30 17:17 ` Logan Gunthorpe
[not found] ` <bdf03cd5-f5b1-4b78-a40e-b24024ca8c9f-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-01-30 18:56 ` Jason Gunthorpe
2019-01-30 18:56 ` Jason Gunthorpe
[not found] ` <20190130185652.GB17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 19:22 ` Jerome Glisse
2019-01-30 19:22 ` Jerome Glisse
2019-01-30 19:38 ` Jason Gunthorpe
[not found] ` <20190130193759.GE17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 20:00 ` Logan Gunthorpe
2019-01-30 20:00 ` Logan Gunthorpe
2019-01-30 20:11 ` Jason Gunthorpe
2019-01-30 20:43 ` Jerome Glisse
[not found] ` <20190130204332.GF5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 20:50 ` Jason Gunthorpe
2019-01-30 20:50 ` Jason Gunthorpe
2019-01-30 21:45 ` Jerome Glisse
2019-01-30 21:45 ` Jerome Glisse
[not found] ` <20190130214525.GG5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 21:56 ` Jason Gunthorpe
2019-01-30 21:56 ` Jason Gunthorpe
2019-01-30 22:30 ` Jerome Glisse
2019-01-30 22:30 ` Jerome Glisse
[not found] ` <20190130223027.GH5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 22:33 ` Jason Gunthorpe
2019-01-30 22:33 ` Jason Gunthorpe
2019-01-30 22:47 ` Jerome Glisse
2019-01-30 22:47 ` Jerome Glisse
[not found] ` <20190130224705.GI5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 22:51 ` Jason Gunthorpe
2019-01-30 22:51 ` Jason Gunthorpe
2019-01-30 22:58 ` Jerome Glisse
2019-01-30 22:58 ` Jerome Glisse
[not found] ` <20190130192234.GD5061-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-30 19:52 ` Logan Gunthorpe
2019-01-30 19:52 ` Logan Gunthorpe
2019-01-30 20:35 ` Jerome Glisse
2019-01-29 20:58 ` Jason Gunthorpe
2019-01-30 8:02 ` Christoph Hellwig
2019-01-30 10:33 ` Koenig, Christian
2019-01-30 15:55 ` Jerome Glisse
2019-01-30 17:26 ` Christoph Hellwig
2019-01-30 17:32 ` Logan Gunthorpe
2019-01-30 17:39 ` Jason Gunthorpe
2019-01-30 18:05 ` Jerome Glisse
2019-01-30 17:44 ` Jason Gunthorpe
2019-01-30 18:13 ` Logan Gunthorpe
2019-01-30 18:50 ` Jerome Glisse
2019-01-31 8:02 ` Christoph Hellwig
2019-01-31 15:03 ` Jerome Glisse
2019-01-30 19:19 ` Jason Gunthorpe
[not found] ` <20190130191946.GD17080-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2019-01-30 19:48 ` Logan Gunthorpe
2019-01-30 19:48 ` Logan Gunthorpe
2019-01-30 20:44 ` Jason Gunthorpe
2019-01-31 8:05 ` Christoph Hellwig
2019-01-31 15:11 ` Jerome Glisse
2019-01-29 17:47 ` [RFC PATCH 4/5] mm/hmm: add support for peer to peer to HMM device memory jglisse
2019-01-29 17:47 ` jglisse
2019-01-29 17:47 ` [RFC PATCH 5/5] mm/hmm: add support for peer to peer to special device vma jglisse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190129210007.GO3176@redhat.com \
--to=jglisse@redhat.com \
--cc=Felix.Kuehling@amd.com \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jgg@mellanox.com \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=m.szyprowski@samsung.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.