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
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
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
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
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
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
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
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
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
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
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
> 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
>
> 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
> 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
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
15 matches
Mail list logo