Re: [PATCH v3 4/7] PCI: OF: Initialize dev->fwnode appropriately

On Fri, Oct 12, 2018 at 03:59:14PM +0100, Jean-Philippe Brucker wrote: > For PCI devices that have an OF node, set the fwnode as well. This way > drivers that rely on fwnode don't need the special case described by > commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately"). > >

Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu

s/iommu/IOMMU/ in subject On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote: > Using the iommu-map binding, endpoints in a given PCI domain can be > managed by different IOMMUs. Some virtual machines may allow a subset of > endpoints to bypass the IOMMU. In some case the IOMMU

Re: [PATCH v3 0/7] Add virtio-iommu driver

On 12/10/2018 18:00, Michael S. Tsirkin wrote: > This all looks good to me. Minor nits: > - I think DEBUG mode is best just removed for now > - Slightly wrong patch splitup causing a misaligned structure > in uapi until all patches are applied. Thanks a lot for the review, I'll fix these up and

Re: [PATCH v3 5/7] iommu: Add virtio-iommu driver

On 12/10/2018 17:35, Michael S. Tsirkin wrote: >> +list_del(>list); >> +kfree(req); > > So with DEBUG set, this will actually free memory that device still > DMA's into. Hardly pretty. I think you want to mark device broken, > queue the request and then wait for device to

Re: [PATCH 10/10] arm64: use the generic swiotlb_dma_ops

On Fri, Oct 12, 2018 at 04:40:49PM +0200, Christoph Hellwig wrote: > On Fri, Oct 12, 2018 at 02:01:00PM +0100, Robin Murphy wrote: > > On 08/10/18 09:02, Christoph Hellwig wrote: > >> Now that the generic swiotlb code supports non-coherent DMA we can switch > >> to it for arm64. For that we need

Re: [PATCH 08/10] swiotlb: don't dip into swiotlb pool for coherent allocations

On Mon, Oct 08, 2018 at 10:02:44AM +0200, Christoph Hellwig wrote: > All architectures that support swiotlb also have a zone that backs up > these less than full addressing allocations (usually ZONE_DMA32). > > Because of that it is rather pointless to fall back to the global swiotlb > buffer if

Re: [PATCH 04/10] swiotlb: remove the overflow buffer

On Mon, Oct 08, 2018 at 10:02:40AM +0200, Christoph Hellwig wrote: > Like all other dma mapping drivers just return an error code instead > of an actual memory buffer. The reason for the overflow buffer was > that at the time swiotlb was invented there was no way to check for > dma mapping

Re: [PATCH v3 0/7] Add virtio-iommu driver

On Fri, Oct 12, 2018 at 03:59:10PM +0100, Jean-Philippe Brucker wrote: > Implement the virtio-iommu driver, following specification v0.8 [1]. > Changes since v2 [2]: > > * Patches 2-4 allow virtio-iommu to use the PCI transport, since QEMU > would like to phase out the MMIO transport. This

Re: [PATCH v3 6/7] iommu/virtio: Add probe request

On Fri, Oct 12, 2018 at 03:59:16PM +0100, Jean-Philippe Brucker wrote: > When the device offers the probe feature, send a probe request for each > device managed by the IOMMU. Extract RESV_MEM information. When we > encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. > This will

Re: [PATCH v3 5/7] iommu: Add virtio-iommu driver

On Fri, Oct 12, 2018 at 03:59:15PM +0100, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. >

[PATCH v3 7/7] iommu/virtio: Add event queue

The event queue offers a way for the device to report access faults from endpoints. It is implemented on virtqueue #1. Whenever the host needs to signal a fault, it fills one of the buffers offered by the guest and interrupts it. Signed-off-by: Jean-Philippe Brucker ---

[PATCH v3 6/7] iommu/virtio: Add probe request

When the device offers the probe feature, send a probe request for each device managed by the IOMMU. Extract RESV_MEM information. When we encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell other subsystems that there is no need to map the MSI doorbell in the

[PATCH v3 5/7] iommu: Add virtio-iommu driver

The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code transforms calls coming from the IOMMU API into

[PATCH v3 4/7] PCI: OF: Initialize dev->fwnode appropriately

For PCI devices that have an OF node, set the fwnode as well. This way drivers that rely on fwnode don't need the special case described by commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately"). Signed-off-by: Jean-Philippe Brucker --- drivers/pci/of.c | 7 +++ 1 file

[PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu

Using the iommu-map binding, endpoints in a given PCI domain can be managed by different IOMMUs. Some virtual machines may allow a subset of endpoints to bypass the IOMMU. In some case the IOMMU itself is presented as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). Currently, when a PCI root

[PATCH v3 1/7] dt-bindings: virtio-mmio: Add IOMMU description

The nature of a virtio-mmio node is discovered by the virtio driver at probe time. However the DMA relation between devices must be described statically. When a virtio-mmio node is a virtio-iommu device, it needs an "#iommu-cells" property as specified by bindings/iommu/iommu.txt. Otherwise, the

[PATCH v3 2/7] dt-bindings: virtio: Add virtio-pci-iommu node

Some systems implement virtio-iommu as a PCI endpoint. The operating systems needs to discover the relationship between IOMMU and masters long before the PCI endpoint gets probed. Add a PCI child node to describe the virtio-iommu device. The virtio-pci-iommu is conceptually split between a PCI

[PATCH v3 0/7] Add virtio-iommu driver

Implement the virtio-iommu driver, following specification v0.8 [1]. Changes since v2 [2]: * Patches 2-4 allow virtio-iommu to use the PCI transport, since QEMU would like to phase out the MMIO transport. This produces a complex topology where the programming interface of the IOMMU could

Re: [PATCH 10/10] arm64: use the generic swiotlb_dma_ops

On Fri, Oct 12, 2018 at 02:01:00PM +0100, Robin Murphy wrote: > On 08/10/18 09:02, Christoph Hellwig wrote: >> Now that the generic swiotlb code supports non-coherent DMA we can switch >> to it for arm64. For that we need to refactor the existing >> alloc/free/mmap/pgprot helpers to be used as

Re: [RFC PATCH v3 10/10] iommu/sva: Add support for private PASIDs

On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote: > Provide an API for allocating PASIDs and populating them manually. To ease > cleanup and factor allocation code, reuse the io_mm structure for private > PASID. Private io_mm has a NULL mm_struct pointer, and cannot be bound

Re: [PATCH 10/10] arm64: use the generic swiotlb_dma_ops

On 08/10/18 09:02, Christoph Hellwig wrote: Now that the generic swiotlb code supports non-coherent DMA we can switch to it for arm64. For that we need to refactor the existing alloc/free/mmap/pgprot helpers to be used as the architecture hooks, and implement the standard

Re: [PATCH v4 1/2] dt-bindings: arm-smmu: Add binding doc for Qcom smmu-500

On 10/12/2018 3:46 AM, Rob Herring wrote: On Thu, 11 Oct 2018 15:19:29 +0530, Vivek Gautam wrote: Qcom's implementation of arm,mmu-500 works well with current arm-smmu driver implementation. Adding a soc specific compatible along with arm,mmu-500 makes the bindings future safe.