Re: [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling

2017-04-13 Thread Bjorn Helgaas
I tentatively applied both patches to pci/host-thunder for v4.12. However, I am concerned about the topology here: On Thu, Apr 13, 2017 at 08:30:45PM +, Jayachandran C wrote: > On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the > PCI topology is slightly unusual. For a

[PATCH v5 1/2] PCI: Add device flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT

2017-04-13 Thread Jayachandran C
Add a new quirk flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT to limit the DMA alias search to go no further than the bridge where the IOMMU unit is attached. The flag will be used to indicate a bridge device which forwards the address translation requests to the IOMMU, i.e where the interrupt and DMA

[PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling

2017-04-13 Thread Jayachandran C
On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the PCI topology is slightly unusual. For a multi-node system, it looks like: 00:00.0 [PCI] bridge to [bus 01-1e] 01:0a.0 [PCI-PCIe bridge, type 8] bridge to [bus 02-04] 02:00.0 [PCIe root port, type 4] bridge to [bus

[PATCH v5 0/2] Handle Cavium ThunderX2 PCI topology quirk

2017-04-13 Thread Jayachandran C
Hi Bjorn, Here's v5 of the patchset with an updated commit message based on your suggestion. I have added a paragraph at the end about MSI-X as well. This is the newest in the series based on the discussion here: https://www.spinics.net/lists/arm-kernel/msg575581.html Previous discussions and

Re: [PATCH] iommu/dma: Setup iova_domain granule for IOMMU_DMA_MSI cookies

2017-04-13 Thread Nate Watterson
Hi Robin, On 4/13/2017 7:21 AM, Robin Murphy wrote: Hi Nate, On 13/04/17 09:55, Nate Watterson wrote: Currently, the __iommu_dma_{map/free} functions call iova_{offset/align} making them unsuitable for use with iommu_domains having an IOMMU_DMA_MSI cookie since the cookie's iova_domain

Re: [PATCH] iommu/dma: Setup iova_domain granule for IOMMU_DMA_MSI cookies

2017-04-13 Thread Shanker Donthineni
Hi Robin, I tested your changes and the device pass-through feature works fine on QDF2400 server platform. Maybe Nate comments on the patch contents but it fixes the problem. @@ -317,13 +317,13 @@ static void iommu_dma_free_iova(struct iommu_dma_cookie *cookie, dma_addr_t

Re: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

2017-04-13 Thread Jean-Philippe Brucker
On 13/04/17 09:41, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Saturday, April 8, 2017 3:18 AM >> >> This is the initial proposal for a paravirtualized IOMMU device using >> virtio transport. It contains a description of the device, a Linux driver, >> and a toy implementation in

Re: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

2017-04-13 Thread Jean-Philippe Brucker
On 13/04/17 09:16, Tian, Kevin wrote: >> From: Jason Wang >> Sent: Wednesday, April 12, 2017 5:07 PM >> >> On 2017年04月08日 03:17, Jean-Philippe Brucker wrote: >>> This is the initial proposal for a paravirtualized IOMMU device using >>> virtio transport. It contains a description of the device, a

Re: [RFC PATCH] of: Fix DMA configuration for non-DT masters

2017-04-13 Thread Oza Oza via iommu
On Wed, Mar 29, 2017 at 11:12 PM, Robin Murphy wrote: > On 29/03/17 06:46, Oza Oza wrote: >> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza wrote: >>> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy wrote: For PCI masters not

Re: [PATCH] iommu/dma: Setup iova_domain granule for IOMMU_DMA_MSI cookies

2017-04-13 Thread Robin Murphy
Hi Nate, On 13/04/17 09:55, Nate Watterson wrote: > Currently, the __iommu_dma_{map/free} functions call iova_{offset/align} > making them unsuitable for use with iommu_domains having an IOMMU_DMA_MSI > cookie since the cookie's iova_domain member, iovad, is uninitialized. > > Now that

[PATCH] iommu/dma: Setup iova_domain granule for IOMMU_DMA_MSI cookies

2017-04-13 Thread Nate Watterson
Currently, the __iommu_dma_{map/free} functions call iova_{offset/align} making them unsuitable for use with iommu_domains having an IOMMU_DMA_MSI cookie since the cookie's iova_domain member, iovad, is uninitialized. Now that iommu_dma_get_msi_page() calls __iommu_dma_map() regardless of cookie

RE: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

2017-04-13 Thread Tian, Kevin
> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > This is the initial proposal for a paravirtualized IOMMU device using > virtio transport. It contains a description of the device, a Linux driver, > and a toy implementation in kvmtool. With this prototype, you can >

RE: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

2017-04-13 Thread Tian, Kevin
> From: Jason Wang > Sent: Wednesday, April 12, 2017 5:07 PM > > On 2017年04月08日 03:17, Jean-Philippe Brucker wrote: > > This is the initial proposal for a paravirtualized IOMMU device using > > virtio transport. It contains a description of the device, a Linux driver, > > and a toy implementation

RE: [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

2017-04-13 Thread Tian, Kevin
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, April 12, 2017 9:22 PM > [...] > By my limited understanding of VT-d details: The stolen memory is never > directly accessed by i915 driver (because CPU access doesn't work even > in DOM0). It is only used through

Re: [PATCH v4 2/2] PCI: quirks: Fix ThunderX2 dma alias handling

2017-04-13 Thread Jon Masters
On 04/04/2017 10:28 AM, Robin Murphy wrote: > So (at the risk of Jon mooing at me) m -- Computer Architect | Sent from my Fedora powered laptop ___ iommu mailing list iommu@lists.linux-foundation.org