All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Dutile <ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org
Subject: Re: [RFC PATCH v2 1/2] pci: Create PCIe requester ID interface
Date: Fri, 26 Jul 2013 16:04:59 -0400	[thread overview]
Message-ID: <51F2D66B.8040607@redhat.com> (raw)
In-Reply-To: <20130726194813.GA20021-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

On 07/26/2013 03:48 PM, Bjorn Helgaas wrote:
> On Thu, Jul 25, 2013 at 02:25:04PM -0400, Don Dutile wrote:
>> On 07/25/2013 01:19 PM, Bjorn Helgaas wrote:
>>> On Wed, Jul 24, 2013 at 04:42:03PM -0400, Don Dutile wrote:
>>>> On 07/23/2013 06:35 PM, Bjorn Helgaas wrote:
>>>>> On Thu, Jul 11, 2013 at 03:03:27PM -0600, Alex Williamson wrote:
>>>>>> + * pcie_for_each_requester - Call callback @fn on each devices and DMA source
>>>>>> + *                           from @requestee to the PCIe requester ID visible
>>>>>> + *                           to @bridge.
>>>>>
>>>>> Transactions from a device may appear with one of several requester IDs,
>>>>> but there's not necessarily an actual pci_dev for each ID, so I think the
>>>> ditto above; have to have a pdev for each id....
>>>
>>> This *might* be true, but I don't think we should rely on it.  For
>>> example:
>>>
>>>    00:1c.0 PCIe to PCI bridge to [bus 01]
>>>    01:01.0 PCI endpoint
>>>
>>> The bridge will take ownership of DMA transactions from the 01:01.0
>>> endpoint.  An IOMMU on bus 00 will see a bridge-assigned requester
>>> ID of 01:00.0 (subordinate bus number, devfn zero), but there is no
>>> 01:00.0 device.
>>>
>> Clarification:
>> I meant that each requester-id must have at least 1 PCI device associated
>> with it.
>
> I don't think that's true, as in the example above.  Requester ID
> 0x0100 has no pci_dev associated with it.  What am I missing?
>
> Maybe you mean that requester ID 0x0100 is associated with pci_dev
> 01:01.0 in the sense that DMAs from 01:01.0 appear with that ID?
yes.
> That's true, but I can't think of a reason why we would start with
> ID 0x0100 and try to look up 01:01.0 from it.  And of course, if you
other than to figure out errant device behavior, or a bug in sw. ;)

> *did* try to look up the device, there could be several of them.
>
> Bjorn
What's most important for the consumers (IOMMUs) is to get all the requester-id's
related to a (p)dev for mapping & unmapping setup & teardown, resp.

WARNING: multiple messages have this Message-ID (diff)
From: Don Dutile <ddutile@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	linux-pci@vger.kernel.org, joro@8bytes.org,
	iommu@lists.linux-foundation.org, acooks@gmail.com,
	dwmw2@infradead.org
Subject: Re: [RFC PATCH v2 1/2] pci: Create PCIe requester ID interface
Date: Fri, 26 Jul 2013 16:04:59 -0400	[thread overview]
Message-ID: <51F2D66B.8040607@redhat.com> (raw)
In-Reply-To: <20130726194813.GA20021@google.com>

On 07/26/2013 03:48 PM, Bjorn Helgaas wrote:
> On Thu, Jul 25, 2013 at 02:25:04PM -0400, Don Dutile wrote:
>> On 07/25/2013 01:19 PM, Bjorn Helgaas wrote:
>>> On Wed, Jul 24, 2013 at 04:42:03PM -0400, Don Dutile wrote:
>>>> On 07/23/2013 06:35 PM, Bjorn Helgaas wrote:
>>>>> On Thu, Jul 11, 2013 at 03:03:27PM -0600, Alex Williamson wrote:
>>>>>> + * pcie_for_each_requester - Call callback @fn on each devices and DMA source
>>>>>> + *                           from @requestee to the PCIe requester ID visible
>>>>>> + *                           to @bridge.
>>>>>
>>>>> Transactions from a device may appear with one of several requester IDs,
>>>>> but there's not necessarily an actual pci_dev for each ID, so I think the
>>>> ditto above; have to have a pdev for each id....
>>>
>>> This *might* be true, but I don't think we should rely on it.  For
>>> example:
>>>
>>>    00:1c.0 PCIe to PCI bridge to [bus 01]
>>>    01:01.0 PCI endpoint
>>>
>>> The bridge will take ownership of DMA transactions from the 01:01.0
>>> endpoint.  An IOMMU on bus 00 will see a bridge-assigned requester
>>> ID of 01:00.0 (subordinate bus number, devfn zero), but there is no
>>> 01:00.0 device.
>>>
>> Clarification:
>> I meant that each requester-id must have at least 1 PCI device associated
>> with it.
>
> I don't think that's true, as in the example above.  Requester ID
> 0x0100 has no pci_dev associated with it.  What am I missing?
>
> Maybe you mean that requester ID 0x0100 is associated with pci_dev
> 01:01.0 in the sense that DMAs from 01:01.0 appear with that ID?
yes.
> That's true, but I can't think of a reason why we would start with
> ID 0x0100 and try to look up 01:01.0 from it.  And of course, if you
other than to figure out errant device behavior, or a bug in sw. ;)

> *did* try to look up the device, there could be several of them.
>
> Bjorn
What's most important for the consumers (IOMMUs) is to get all the requester-id's
related to a (p)dev for mapping & unmapping setup & teardown, resp.


  parent reply	other threads:[~2013-07-26 20:04 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-11 21:03 [RFC PATCH v2 0/2] pci/iommu: PCIe requester ID interface Alex Williamson
     [not found] ` <20130711204439.1701.90503.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-07-11 21:03   ` [RFC PATCH v2 1/2] pci: Create " Alex Williamson
2013-07-11 21:03     ` Alex Williamson
     [not found]     ` <20130711210326.1701.56478.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-07-23 22:35       ` Bjorn Helgaas
2013-07-23 22:35         ` Bjorn Helgaas
     [not found]         ` <20130723223533.GB19765-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-07-23 23:21           ` Alex Williamson
2013-07-23 23:21             ` Alex Williamson
     [not found]             ` <1374621703.15429.98.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-07-24 15:03               ` Andrew Cooks
2013-07-24 15:03                 ` Andrew Cooks
     [not found]                 ` <CAJtEV7b3JR9J7UN_gzL6deD1JDBTfhQjGQzd_TRMLcWX2aoUfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-24 15:50                   ` Alex Williamson
2013-07-24 15:50                     ` Alex Williamson
2013-07-24 16:47               ` Bjorn Helgaas
2013-07-24 16:47                 ` Bjorn Helgaas
     [not found]                 ` <CAErSpo6bcGCjqdxn-bz_vjo+HsAiOxDu=--mD7veEZ9f7k+gyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-24 18:12                   ` Alex Williamson
2013-07-24 18:12                     ` Alex Williamson
2013-07-24 23:24                     ` Bjorn Helgaas
     [not found]                       ` <20130724232427.GA9272-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-07-25 17:56                         ` Alex Williamson
2013-07-25 17:56                           ` Alex Williamson
2013-07-26 21:54                           ` Bjorn Helgaas
2013-07-29 16:06                             ` Alex Williamson
2013-07-29 21:02                               ` Bjorn Helgaas
     [not found]                                 ` <CAErSpo7pfCtTm5Cq=VixPTKMpM4VQpDr+ZmS5qMw32z6ABu0xQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-29 22:32                                   ` Alex Williamson
2013-07-29 22:32                                     ` Alex Williamson
2013-08-01 22:08                                     ` Bjorn Helgaas
     [not found]                                       ` <CAErSpo5+-r3qMca1_Kvt3jJ6OP6Q7--4VmTo3fWJ0y4CPewgEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-02 16:59                                         ` Alex Williamson
2013-08-02 16:59                                           ` Alex Williamson
     [not found]                                           ` <1375462795.31262.327.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-04-03 21:48                                             ` Bjorn Helgaas
2014-04-03 21:48                                               ` Bjorn Helgaas
     [not found]                                               ` <CAErSpo5p+6yt8ZyVuLnJTiKAWZWq9ixQQu78nD-bNFkw4ntWmw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-04-04  2:51                                                 ` Alex Williamson
2014-04-04  2:51                                                   ` Alex Williamson
     [not found]                                                   ` <1396579914.3215.36.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-04-04 15:00                                                     ` Bjorn Helgaas
2014-04-04 15:00                                                       ` Bjorn Helgaas
2013-07-29 21:03                               ` Don Dutile
     [not found]                                 ` <51F6D8BB.4040901-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-29 22:55                                   ` Alex Williamson
2013-07-29 22:55                                     ` Alex Williamson
2013-07-24 20:42           ` Don Dutile
2013-07-24 20:42             ` Don Dutile
     [not found]             ` <51F03C1B.2070002-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-24 21:22               ` Alex Williamson
2013-07-24 21:22                 ` Alex Williamson
     [not found]                 ` <1374700966.16522.19.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-07-25 18:38                   ` Don Dutile
2013-07-25 18:38                     ` Don Dutile
2013-07-25 17:19               ` Bjorn Helgaas
2013-07-25 17:19                 ` Bjorn Helgaas
     [not found]                 ` <20130725171958.GB9272-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-07-25 18:25                   ` Don Dutile
2013-07-25 18:25                     ` Don Dutile
     [not found]                     ` <51F16D80.5040208-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-26 19:48                       ` Bjorn Helgaas
2013-07-26 19:48                         ` Bjorn Helgaas
     [not found]                         ` <20130726194813.GA20021-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-07-26 20:04                           ` Don Dutile [this message]
2013-07-26 20:04                             ` Don Dutile
2013-07-11 21:03   ` [RFC PATCH v2 2/2] iommu/intel: Make use of " Alex Williamson
2013-07-11 21:03     ` Alex Williamson

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=51F2D66B.8040607@redhat.com \
    --to=ddutile-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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.