From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Gerald Schaefer
<gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Sebastian Ott
<sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support
Date: Thu, 27 Apr 2017 23:03:25 +0200 [thread overview]
Message-ID: <20170427210325.GE1332@8bytes.org> (raw)
In-Reply-To: <20170427201018.70c8be5a@thinkpad>
Hi Gerald,
thanks for your reply. I have some more questions, please see below.
On Thu, Apr 27, 2017 at 08:10:18PM +0200, Gerald Schaefer wrote:
> Well, there is a separate zpci_dev for each pci_dev on s390,
> and each of those has its own separate dma-table (thus not shared).
Is that true for all functions of a PCIe card, so does every function of
a device has its own zpci_dev structure and thus its own DMA-table?
My assumption came from the fact that the zpci_dev is read from
pci_dev->sysdata, which is propagated there from the pci_bridge
through the pci_root_bus structures.
> Given this "separate zpci_dev for each pci_dev" situation, I don't
> see what this update actually changes, compared to the previous code,
> see also my comments to that patch.
The add_device call-back is invoked for every function of a pci-device,
because each function gets its own pci_dev structure. Also we usually
group all functions of a PCI-device together into one iommu-group,
because we don't trust that the device isolates its functions from each
other.
Regards,
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support
Date: Thu, 27 Apr 2017 23:03:25 +0200 [thread overview]
Message-ID: <20170427210325.GE1332@8bytes.org> (raw)
In-Reply-To: <20170427201018.70c8be5a@thinkpad>
Hi Gerald,
thanks for your reply. I have some more questions, please see below.
On Thu, Apr 27, 2017 at 08:10:18PM +0200, Gerald Schaefer wrote:
> Well, there is a separate zpci_dev for each pci_dev on s390,
> and each of those has its own separate dma-table (thus not shared).
Is that true for all functions of a PCIe card, so does every function of
a device has its own zpci_dev structure and thus its own DMA-table?
My assumption came from the fact that the zpci_dev is read from
pci_dev->sysdata, which is propagated there from the pci_bridge
through the pci_root_bus structures.
> Given this "separate zpci_dev for each pci_dev" situation, I don't
> see what this update actually changes, compared to the previous code,
> see also my comments to that patch.
The add_device call-back is invoked for every function of a pci-device,
because each function gets its own pci_dev structure. Also we usually
group all functions of a PCI-device together into one iommu-group,
because we don't trust that the device isolates its functions from each
other.
Regards,
Joerg
next prev parent reply other threads:[~2017-04-27 21:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 15:28 [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support Joerg Roedel
2017-04-27 15:28 ` Joerg Roedel
[not found] ` <1493306905-32334-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-27 15:28 ` [PATCH 1/2] iommu/s390: Fix IOMMU groups Joerg Roedel
2017-04-27 15:28 ` Joerg Roedel
[not found] ` <1493306905-32334-2-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-27 18:11 ` Gerald Schaefer
2017-04-27 18:11 ` Gerald Schaefer
2017-04-27 21:12 ` Joerg Roedel
2017-04-27 21:12 ` Joerg Roedel
[not found] ` <20170427211232.GF1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 13:20 ` Gerald Schaefer
2017-04-28 13:20 ` Gerald Schaefer
2017-04-28 14:40 ` Joerg Roedel
2017-04-28 14:40 ` Joerg Roedel
2017-04-28 17:50 ` kbuild test robot
2017-04-28 17:50 ` kbuild test robot
2017-04-27 15:28 ` [PATCH 2/2] iommu/s390: Add support for iommu_device handling Joerg Roedel
2017-04-27 15:28 ` Joerg Roedel
[not found] ` <1493306905-32334-3-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 23:02 ` kbuild test robot
2017-04-28 23:02 ` kbuild test robot
2017-04-27 18:10 ` [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support Gerald Schaefer
2017-04-27 18:10 ` Gerald Schaefer
2017-04-27 21:03 ` Joerg Roedel [this message]
2017-04-27 21:03 ` Joerg Roedel
[not found] ` <20170427210325.GE1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 12:46 ` Gerald Schaefer
2017-04-28 12:46 ` Gerald Schaefer
2017-04-28 14:55 ` Joerg Roedel
2017-04-28 14:55 ` Joerg Roedel
[not found] ` <20170428145513.GH1332-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-04-28 15:25 ` Sebastian Ott
2017-04-28 15:25 ` Sebastian Ott
[not found] ` <alpine.LFD.2.20.1704281709350.1788-+lzQMq5bIdMXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2017-04-28 22:29 ` Joerg Roedel
2017-04-28 22:29 ` Joerg Roedel
2017-04-28 18:06 ` Gerald Schaefer
2017-04-28 18:06 ` Gerald Schaefer
2017-04-28 22:40 ` Joerg Roedel
2017-04-28 22:40 ` Joerg Roedel
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=20170427210325.GE1332@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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.