On Sun, Aug 02, 2020 at 08:46:48PM +0200, Borislav Petkov wrote:
> On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> > Because the value ~0 has a meaning to some drivers and only
>
> No, ~0 means that the PCI read failed. For *every* PCI device I know.
Wait, I'm not convinced ye
SI" here in the commit log,
but nice cleanup and:
Acked-by: Bjorn Helgaas
Minor comments below.
> Signed-off-by: Thomas Gleixner
> Cc: linux-...@vger.kernel.org
> ---
> arch/x86/kernel/apic/msi.c |2 +-
> drivers/pci/msi.c | 13 ++---
> include/li
pt remapping.
>
> Override the default bus token.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn Helgaas
> Cc: Lorenzo Pieralisi
> Cc: Jonathan Derrick
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/controller/vmd.c |6 ++
>
On Fri, Aug 21, 2020 at 02:24:54AM +0200, Thomas Gleixner wrote:
> If an architecture does not require the MSI setup/teardown fallback
> functions, then allow them to be replaced by stub functions which emit a
> warning.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn He
gt; override in irq remapping.
>
> Signed-off-by: Thomas Gleixner
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
s|PCI: MSI:|PCI/MSI:| in the subject if feasible.
> ---
> drivers/pci/msi.c | 22 ++
> include/linux/msi.
the #ifdeffery to the header file where it is
> not in the way.
>
> Signed-off-by: Thomas Gleixner
> Cc: linux-...@vger.kernel.org
Nice cleanup, thanks. Glad to get rid of the useless initializer,
too.
Acked-by: Bjorn Helgaas
> ---
> arch/x86/include/asm/pci_x86.h |
On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
> Rename it to x86_msi_prepare() and handle the allocation type setup
> depending on the device type.
I see what you're doing, but the subject reads a little strangely
("pci_msi_prepare() handling non-PCI" stuff) since it doesn't men
On Tue, Aug 25, 2020 at 11:28:30PM +0200, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 15:07, Bjorn Helgaas wrote:
> >> + * The arch hooks to setup up msi irqs. Default functions are implemented
> >> + * as weak symbols so that they /can/ be overriden by archit
On Tue, Aug 25, 2020 at 11:30:41PM +0200, Thomas Gleixner wrote:
> On Tue, Aug 25 2020 at 15:24, Bjorn Helgaas wrote:
> > On Fri, Aug 21, 2020 at 02:24:58AM +0200, Thomas Gleixner wrote:
> >> Rename it to x86_msi_prepare() and handle the allocation type setup
> >> d
[+cc Rob,
cover https://lore.kernel.org/r/20200826111628.794979...@linutronix.de/
this https://lore.kernel.org/r/20200826112333.992429...@linutronix.de/]
On Wed, Aug 26, 2020 at 01:17:02PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled in
In subject,
PCI/ACPI: ...
would be consistent with previous history (at least things coming
through the PCI tree :)).
On Fri, Mar 25, 2022 at 11:46:08AM -0700, Rajat Jain wrote:
> The "DmaProperty" is supported and documented by Microsoft here:
> https://docs.microsoft.com/en-us/windows-hardwa
On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> > You might consider using a linear tree instead of the topic branches,
> > topics are tricky and I'm not sure it helps a small subsystem so much.
> > Conflicts between
On Thu, Apr 14, 2022 at 04:15:47PM -0700, Rajat Jain via iommu wrote:
> On Thu, Apr 7, 2022 at 12:17 PM Bjorn Helgaas wrote:
> > On Fri, Mar 25, 2022 at 11:46:08AM -0700, Rajat Jain wrote:
> > > Support the "DmaProperty" with the same semantics. This is useful for
>
From: Bjorn Helgaas
Fix misspellings of "physical".
Signed-off-by: Bjorn Helgaas
---
include/linux/intel-iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 09c6a0bf3892..3ae86385b222 100644
---
On Thu, Feb 04, 2021 at 12:09:06PM -0700, Jon Derrick wrote:
> VMD will retransmit child device MSI/X using its own MSI/X table and
> requester-id. This limits the number of MSI/X available to the whole
> child device domain to the number of VMD MSI/X interrupts.
>
> Some VMD devices have a mode w
all to use a passed in gfp_mask and don't print that
> message if the buffer fails to be allocated.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/p2pdma.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
On Thu, Mar 11, 2021 at 04:31:32PM -0700, Logan Gunthorpe wrote:
> In order to use upstream_bridge_distance_warn() from a dma_map function,
> it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it
> might sleep.
>
> In order to avoid this, try to get the host bridge's device from
>
On Tue, Apr 20, 2021 at 07:10:06AM +0100, Christoph Hellwig wrote:
> On Mon, Apr 19, 2021 at 05:30:49PM -0700, Rajat Jain wrote:
> > The current flag name "untrusted" is not correct as it is populated
> > using the firmware property "external-facing" for the parent ports. In
> > other words, the fi
On Fri, May 07, 2021 at 12:49:53PM +, Wang Xingang wrote:
> From: Xingang Wang
>
> When request ACS for PCI device in of_iommu_configure, the pci device
> has already been scanned and added with 'pci_acs_enable=0'. So the
> pci_request_acs() in current procedure does not work for enabling ACS
[+cc John, who tested 6bf6c24720d3]
On Fri, May 21, 2021 at 03:03:24AM +, Wang Xingang wrote:
> From: Xingang Wang
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be ena
On Fri, May 21, 2021 at 03:03:24AM +, Wang Xingang wrote:
> From: Xingang Wang
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be enabled when IOMMU is detected for the
>
[+cc Marek, Anders, Robin]
On Fri, Aug 20, 2021 at 02:57:12PM -0500, Bjorn Helgaas wrote:
> On Fri, May 21, 2021 at 03:03:24AM +, Wang Xingang wrote:
> > From: Xingang Wang
> >
> > When booting with devicetree, the pci_request_acs() is called after the
> > enumer
From: Bjorn Helgaas
719a19335692 ("iommu/vt-d: Tweak the description of a DMA fault") changed
the DMA fault reason from hex to decimal. It also added "0x" prefixes to
the PCI bus/device, e.g.,
- DMAR: [INTR-REMAP] Request device [00:00.5]
+ DMAR: [INTR-REMAP] Request
ency: At present,
> XEN_PV con only be set when X86 is also enabled. In general an
> architecture supporting Xen PV (and PCI) would want to have this driver
> built.
s/con only/can only/
> Signed-off-by: Jan Beulich
> Reviewed-by: Stefano Stabellini
Acked-by: Bjorn Helgaas
&g
On Fri, Sep 11, 2020 at 03:55:34PM +0530, Srinath Mannam wrote:
> Fix IOVA reserve failure in the case when address of first memory region
> listed in dma-ranges is equal to 0x0.
>
> Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
> address")
> Signed-off-by: Srinath Mann
On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote:
> When enabling ACS, enable translation blocking for external facing ports
> and untrusted devices.
>
> Signed-off-by: Rajat Jain
Applied (slightly modified) to pci/acs for v5.10, thanks!
I think the warning is superfluous because ever
On Tue, Jul 14, 2020 at 01:15:40PM -0700, Rajat Jain wrote:
> The ACS "Translation Blocking" bit blocks the translated addresses from
> the devices. We don't expect such traffic from devices unless ATS is
> enabled on them. A device sending such traffic without ATS enabled,
> indicates malicious in
[+cc IOMMU and NVMe folks]
Sorry, I forgot to forward this to linux-pci when it was first
reported.
Apparently this happens with v5.9-rc3, and may be related to
50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in hint"),
which appeared in v5.8-rc3.
There are several dmesg logs and prop
On Fri, Aug 21, 2020 at 03:15:39PM +0200, Jean-Philippe Brucker wrote:
> Platforms without device-tree nor ACPI can provide a topology
> description embedded into the virtio config space. Parse it.
>
> Use PCI FIXUP to probe the config space early, because we need to
> discover the topology before
On Fri, Sep 25, 2020 at 10:12:43AM +0200, Jean-Philippe Brucker wrote:
> On Thu, Sep 24, 2020 at 10:22:03AM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 21, 2020 at 03:15:39PM +0200, Jean-Philippe Brucker wrote:
> > > + /* Perform the init sequence before we can read the con
https://bugzilla.kernel.org/show_bug.cgi?id=209321
Not much detail in the bugzilla yet, but apparently this started in
v5.8.0-rc1:
DMAR: [DMA Read] Request device [03:00.0] PASID fault addr fffd3000
[fault reason 06] PTE Read access is not set
Currently assigned to Driver/PCI, but no
ork on conventional PCI as
well as PCIe.
> Signed-off-by: Christoph Hellwig
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/p2pdma.c | 20
> 1 file changed, 20 deletions(-)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index de1c331dbe
s|PCI/p2p: cleanup up __pci_p2pdma_map_sg|PCI/P2PDMA: Cleanup up
__pci_p2pdma_map_sg|
to match history.
On Wed, Nov 04, 2020 at 10:50:51AM +0100, Christoph Hellwig wrote:
> Remove the pointless paddr variable that was only used once.
>
> Signed-off-by: Christoph Hellwig
Acked-
On Fri, Nov 06, 2020 at 10:00:24AM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
> dma map functions to determine how to map a given p2pdma page.
s/dma/DMA/ for consistency (also below in function comment)
> pci_p2pdma_bus_offset() is also ad
Kuehling, Felix
> > Cc: Will Deacon ; linux-ker...@vger.kernel.org;
> > linux- p...@vger.kernel.org; iommu@lists.linux-foundation.org; Bjorn
> > Helgaas ; Joerg Roedel ; Zhu,
> > Changfeng
> > Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as
>
On Wed, Dec 16, 2020 at 07:24:30PM +0800, Zhou Wang wrote:
> On 2020/6/23 23:04, Bjorn Helgaas wrote:
> > On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
> >> Have studied _DSM method, two issues we met comparing using quirk.
> >>
> >>
gt; as the driver for OpenCAPI coherent accelerator (OCXL).
Strictly speaking, not really relevant for the commit log.
> Cc: David E. Box
> Cc: Jonathan Cameron
> Cc: Bjorn Helgaas
> Cc: Dan Williams
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> C
> Signed-off-by: Logan Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/p2pdma.c | 24 +-
> include/linux/pci-p2pdma.h | 41 ++
> 2 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/
o
> pages will be present in the VMA and a subsequent access will result
> in a SIGBUS error.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Bjorn Helgaas
I would capitalize "Introduce" in the subject line.
> ---
> drivers/pci/p2pdma.c | 263 +++
re to come from userspace then there's no
> way to ensure the path was checked ahead of time.
>
> With this change it's no longer invalid to call pci_p2pdma_map_sg()
> before the mapping type is calculated so drop the WARN_ON when that
> is the case.
>
> Signed-off
On Thu, Sep 16, 2021 at 05:40:53PM -0600, Logan Gunthorpe wrote:
> This interface is superseded by support in dma_map_sg() which now supports
> heterogeneous scatterlists. There are no longer any users, so remove it.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Bjorn Hel
across calls and avoid needing to lookup into the xarray for
> every page.
>
> Also add pci_p2pdma_map_bus_segment() which is useful for IOMMU
> dma_map_sg() implementations where the sg segment containing the page
> differs from the sg segment containing the DMA address.
>
On Fri, Nov 05, 2021 at 12:56:09PM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On a PowerEdge T440/021KCD, BIOS 2.11.2 04/22/2021, Linux 5.10.70 takes
> almost five seconds to initialize PCI. According to the timestamps, 1.5 s
> are from assigning the PCI devices to the 142 IOMMU groups.
On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote:
> From the perspective of who is initiating the device to do DMA, device
> DMA could be divided into the following types:
>
> DMA_OWNER_KERNEL: kernel device driver intiates the DMA
> DMA_OWNER_USER: userspace device driver
On Mon, Nov 15, 2021 at 10:05:45AM +0800, Lu Baolu wrote:
> IOMMU grouping on PCI necessitates that if we lack isolation on a bridge
> then all of the downstream devices will be part of the same IOMMU group
> as the bridge.
I think this means something like: "If a PCIe Switch Downstream Port
lacks
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
> pci_stub allows the admin to block driver binding on a device and make
> it permanently shared with userspace. Since pci_stub does not do DMA,
> it is safe.
Can you elaborate on what "permanently shared with userspace" means
here? I ass
On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote:
> pci_stub allows the admin to block driver binding on a device and make
> it permanently shared with userspace. Since pci_stub does not do DMA,
> it is safe. However the admin must understand that using pci_stub allows
> userspace to attack
On Tue, Nov 16, 2021 at 03:24:29PM +0800, Lu Baolu wrote:
> On 2021/11/16 4:44, Bjorn Helgaas wrote:
> > On Mon, Nov 15, 2021 at 10:05:45AM +0800, Lu Baolu wrote:
> > > IOMMU grouping on PCI necessitates that if we lack isolation on a bridge
> > > then all of the downstr
nthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> --- a/drivers/pci/msi/msi.c
> +++ b/drivers/pci/msi/msi.c
> @@ -889,10 +889,12 @@ static int __pci_enable_msi_range(struc
y: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |2 +-
> drivers/pci/msi/legacy.c|6 +-
> drivers/pci/msi/msi.c | 23 ---
> include/linux/pci.h |1 -
> 4 files changed, 6 insertions(+), 26 del
specific storage for no value.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> arch/powerpc/platforms/pseries/msi.c |4 ++--
> arch/x86/pci/xen.c |2 +-
>
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: Use the setter function
&g
-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c | 16 ++--
> include/linux/msi.h |2 ++
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> --- a
On Mon, Dec 06, 2021 at 11:39:41PM +0100, Thomas Gleixner wrote:
> Use msi_get_vector() and handle the return value to be compatible.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: Handle the INTx case directly
On Fri, Dec 17, 2021 at 02:36:58PM +0800, Lu Baolu wrote:
> The pci_dma_configure() marks the iommu_group as containing only devices
> with kernel drivers that manage DMA.
I'm looking at pci_dma_configure(), and I don't see the connection to
iommu_groups.
> Avoid this default behavior for the
> p
On Fri, Dec 17, 2021 at 02:36:59PM +0800, Lu Baolu wrote:
> IOMMU grouping on PCI necessitates that if we lack isolation on a bridge
> then all of the downstream devices will be part of the same IOMMU group
> as the bridge. The existing vfio framework allows the portdrv driver to
> be bound to the
On Thu, Dec 30, 2021 at 01:34:27PM +0800, Lu Baolu wrote:
> Hi Bjorn,
>
> On 12/30/21 4:42 AM, Bjorn Helgaas wrote:
> > On Fri, Dec 17, 2021 at 02:36:58PM +0800, Lu Baolu wrote:
> > > The pci_dma_configure() marks the iommu_group as containing only devices
> > >
On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote:
> On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> > Multiple devices may be placed in the same IOMMU group because they
> > cannot be isolated from each other. These devices must either be
> > entirely under kernel contr
On Tue, Jan 04, 2022 at 09:56:39AM +0800, Lu Baolu wrote:
> If a switch lacks ACS P2P Request Redirect, a device below the switch can
> bypass the IOMMU and DMA directly to other devices below the switch, so
> all the downstream devices must be in the same IOMMU group as the switch
> itself.
Help
On Tue, Jan 04, 2022 at 03:26:14PM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
>
> > > The existing vfio framework allows the portdrv driver to be bound
> > > to the bridge while its downstream devices are assigned to
On Thu, Jan 06, 2022 at 12:12:35PM +0800, Lu Baolu wrote:
> On 1/5/22 1:06 AM, Bjorn Helgaas wrote:
> > On Tue, Jan 04, 2022 at 09:56:39AM +0800, Lu Baolu wrote:
> > > If a switch lacks ACS P2P Request Redirect, a device below the switch can
> > > bypass the IOMMU and DM
In subject,
s/dma/DMA/ to match the other patches
On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> Multiple PCI devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace con
; usage, avoid this default behavior for the pci_stub. This allows the
> pci_stub still able to be used by the admin to block driver binding after
> applying the DMA ownership to VFIO.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> d
portdrv might
make it unsafe.
> Suggested-by: Jason Gunthorpe
> Suggested-by: Kevin Tian
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pcie/portdrv_pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
On Sun, Apr 15, 2018 at 04:59:44PM +0200, Christoph Hellwig wrote:
> This symbol is now always identical to CONFIG_ARCH_DMA_ADDR_T_64BIT, so
> remove it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Bjorn Helgaas
Please merge this along with the rest of the series; let me know
27;of_map_rid' and there is no
> functional change done in the API.
>
> Signed-off-by: Nipun Gupta
Acked-by: Bjorn Helgaas
> ---
> drivers/iommu/of_iommu.c | 5 +--
> drivers/of/base.c| 102
> +++
> drivers/o
On Thu, May 03, 2018 at 10:23:02AM -0400, Sinan Kaya wrote:
> +Bjorn,
>
> On 5/3/2018 9:59 AM, Joerg Roedel wrote:
> > On Thu, May 03, 2018 at 09:46:34AM -0400, Sinan Kaya wrote:
> >> I also like the idea in general.
> >> Minor nit..
> >>
> >> Shouldn't this be an iommu parameter rather than a PCI
On Sun, Apr 29, 2018 at 09:16:48PM +0300, Gil Kupfer wrote:
> This patch adds noats option to the pci boot parameter.
> When noats is selected, all ATS related functions fail immediately and
> the IOMMU is configured to not use device-iotlb.
>
> Any function that checks for ATS capabilities direct
When you add the changleog, please also fix the subject typo:
- bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
^^^
+ bus: fsl-mc: support dma configure for devices on fsl-mc bus
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gu
[+cc Joerg]
On Mon, Jul 30, 2018 at 09:38:42AM +0200, Christoph Hellwig wrote:
> There is nothing arch specific about PCI or dma-debug, so move this
> call to common code just after registering the bus type.
I assume that previously, even if the user set CONFIG_DMA_API_DEBUG=y
we only got PCI DMA
On Mon, Jul 30, 2018 at 09:38:42AM +0200, Christoph Hellwig wrote:
> There is nothing arch specific about PCI or dma-debug, so move this
> call to common code just after registering the bus type.
>
> Signed-off-by: Christoph Hellwig
Applied with acks from Thomas and Michael to pci/misc for v4.19
[+cc David, Logan, Alex, iommu list]
On Thu, Aug 09, 2018 at 11:14:13AM -0700, Eric Pilmore wrote:
> Didn't get any response on the IRC channel so trying here.
>
> Was wondering if anybody here has used IOAT DMA engines with an
> IOMMU turned on (Xeon based system)? My specific question is really
[+cc Yijing, Dave J, Dave M, Alex]
On Fri, May 01, 2015 at 01:32:12PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Hi,
>
> This patch series adds DMA APIs to map and unmap a struct resource to and from
> a PCI device's IOVA domain, and implements the AMD, Intel, and nommu versions
> o
On Wed, May 6, 2015 at 8:48 PM, Yijing Wang wrote:
> On 2015/5/7 6:18, Bjorn Helgaas wrote:
>> [+cc Yijing, Dave J, Dave M, Alex]
>>
>> On Fri, May 01, 2015 at 01:32:12PM -0500, wda...@nvidia.com wrote:
>>> From: Will Davis
>>>
>>> Hi,
>>&g
On Fri, May 01, 2015 at 01:32:18PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Simply pass through the physical address as the DMA address.
>
> Signed-off-by: Will Davis
> Reviewed-by: Terence Ripperda
> Reviewed-by: John Hubbard
> ---
> arch/x86/kernel/pci-nommu.c | 17 ++
On Fri, May 01, 2015 at 01:32:14PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Add functions to DMA-map and -unmap a resource for a given device. This
> will allow devices to DMA-map a peer device's resource (for example,
> another device's BAR region on PCI) to enable peer-to-peer tra
[+cc Dave for sparc64, Yinghai]
On Fri, May 01, 2015 at 01:32:15PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Simply route these through to the new dma_(un)map_resource APIs.
>
> Signed-off-by: Will Davis
> Reviewed-by: Terence Ripperda
> Reviewed-by: John Hubbard
> ---
> includ
On Thu, May 7, 2015 at 11:23 AM, William Davis wrote:
>
>
>> -Original Message-----
>> From: Bjorn Helgaas [mailto:bhelg...@google.com]
>> Sent: Thursday, May 7, 2015 8:13 AM
>> To: Yijing Wang
>> Cc: William Davis; Joerg Roedel; open list:INTEL IOMMU (V
On Mon, May 11, 2015 at 9:30 AM, Konrad Rzeszutek Wilk
wrote:
> On Thu, May 07, 2015 at 10:19:05AM -0500, Bjorn Helgaas wrote:
>> [+cc Dave for sparc64, Yinghai]
>>
>> On Fri, May 01, 2015 at 01:32:15PM -0500, wda...@nvidia.com wrote:
>> > From: Will Davis
>>
[+cc Dave, Jonathan]
On Mon, May 18, 2015 at 01:25:01PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Add references to both the general API documentation as well as the HOWTO.
>
> Signed-off-by: Will Davis
> ---
> Documentation/DMA-API-HOWTO.txt | 39
On Fri, May 29, 2015 at 12:14:42PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Simply route these through to the new dma_(un)map_resource APIs.
>
> Signed-off-by: Will Davis
> Reviewed-by: Terence Ripperda
> Reviewed-by: John Hubbard
> ---
> include/asm-generic/pci-dma-compat.h |
On Fri, May 29, 2015 at 12:14:44PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Implement 'map_resource' for the AMD IOMMU driver. Generalize the existing
> map_page implementation to operate on a physical address, and make both
> map_page and map_resource wrappers around that helper (a
On Fri, May 29, 2015 at 12:14:46PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Lookup the bus address of the resource by finding the parent host bridge,
> which may be different than the parent host bridge of the target device.
>
> Signed-off-by: Will Davis
> ---
> arch/x86/kernel/p
On Wed, Jul 01, 2015 at 11:06:06AM -0500, Bjorn Helgaas wrote:
> On Fri, May 29, 2015 at 12:14:42PM -0500, wda...@nvidia.com wrote:
> > From: Will Davis
> >
> > Simply route these through to the new dma_(un)map_resource APIs.
> >
> > Signed-off-by: Will Davis
[+cc Alex]
Hi Mark,
On Wed, May 20, 2015 at 08:11:17AM -0400, Mark Hounschell wrote:
> Most currently available hardware doesn't allow reads but will allow
> writes on PCIe peer-to-peer transfers. All current AMD chipsets are
> this way. I'm pretty sure all Intel chipsets are this way also. What
[+cc Mark, Joerg, Konrad, Alex]
Hi Will,
On Wed, Jul 01, 2015 at 01:14:30PM -0500, Will Davis wrote:
> > From: Bjorn Helgaas
> > On Fri, May 29, 2015 at 12:14:46PM -0500, wda...@nvidia.com wrote:
> > > From: Will Davis
> > >
> > > Lookup the bus addres
On Tue, Jul 7, 2015 at 10:41 AM, Alex Williamson
wrote:
> On Tue, 2015-07-07 at 10:15 -0500, Bjorn Helgaas wrote:
>> [+cc Alex]
>>
>> Hi Mark,
>>
>> On Wed, May 20, 2015 at 08:11:17AM -0400, Mark Hounschell wrote:
>> > Most currently available h
[+cc Rafael]
On Tue, Jul 07, 2015 at 01:14:27PM -0400, Mark Hounschell wrote:
> On 07/07/2015 11:15 AM, Bjorn Helgaas wrote:
> >On Wed, May 20, 2015 at 08:11:17AM -0400, Mark Hounschell wrote:
> >>Most currently available hardware doesn't allow reads but will allow
> >
Hi Joerg,
On Thu, Jun 18, 2015 at 10:50:20AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The use of the SR-IOV lock for ATS causes a dead-lock in the
> AMD-IOMMU driver when virtual functions are added that have
> an ATS capability.
>
> The problem is that the VFs will be added to the b
associated VFs have ATS enabled
- Add comment that ATS must be enabled on PF before on VFs
- Require ATS to be disabled on all VFs and PF before changing STU
---
Bjorn Helgaas (11):
iommu/vt-d: Cache PCI ATS state and Invalidate Queue Depth
PCI: Allocate ATS struct during enumeration
_info struct. This is similar to what
amd_iommu.c does.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/intel-iommu.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a98a7b2..50832f1 1
e the PF controls the STU for all the VFs.
Link: http://permalink.gmane.org/gmane.linux.kernel.iommu/9433
Reported-by: Gregor Dick
Signed-off-by: Bjorn Helgaas
---
drivers/pci/ats.c | 98 ---
drivers/pci/probe.c |3 +
drivers/pci/remov
The pci_ats struct is small and will get smaller, so I don't think it's
worth allocating it separately from the pci_dev struct.
Embed the ATS fields directly into struct pci_dev.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/ats.c
The extended capabilities list is linked with 12-bit pointers, and the ATS
Smallest Translation Unit and Invalidate Queue Depth fields are both 5
bits.
Use u16 and u8 to hold the extended capability address and the stu and qdep
values. No functional change.
Signed-off-by: Bjorn Helgaas
We previously returned -ENODEV for devices that don't support ATS (except
that we always returned 0 for VFs, whether or not they support ATS).
For consistency, always return -EINVAL (not -ENODEV) if the device doesn't
support ATS. Return zero for VFs that support ATS.
Signed-off
The ATS setup code in ats_alloc_one() is only used by pci_ats_init(), so
inline it there. No functional change.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Joerg Roedel
---
drivers/pci/ats.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/pci/ats.c b/drivers
Use the pci_physfn() helper rather than looking up physfn by hand.
No functional change.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Joerg Roedel
---
drivers/pci/ats.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index
here now.
Clean up these error paths.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/ats.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 0b5b0ed..67524a7 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.
Move ATS declarations to linux/pci.h so they're all in one place.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Joerg Roedel
---
include/linux/pci-ats.h | 41 -
include/linux/pci.h | 10 +-
2 files changed, 9 insertions(+), 42 dele
Stop caching the Invalidate Queue Depth in struct pci_dev.
pci_ats_queue_depth() is typically called only once per device, and it
returns a fixed value per-device, so callers who need the value frequently
can cache it themselves.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/ats.c |9
301 - 400 of 448 matches
Mail list logo
