[PATCH v2] iommu/amd: Set AMD iommu callbacks for platform bus driver

From: Wan Zongshun AMD has more drivers will use ACPI to platform bus driver later, all those devices need iommu support, for example: eMMC driver. For latest AMD eMMC controller, it will utilize sdhci-acpi.c driver, which will rely on platform bus to match device and

Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

Hi Chalarmala, On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: > Hi Eric, > > Does this series supports gicv3-its emulation? > Do we have a tree with all the dependent patches GICv3 ITS emulation support comes with: [PATCH v4 00/12] KVM: arm64: GICv3 ITS emulation

Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration

Hi Chalamarla, On 05/05/2016 09:22 PM, Chalamarla, Tirumalesh wrote: > > > > > > On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger" > eric.au...@linaro.org> wrote: > >> The user is allowed to register a reserved MSI

[PATCH 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

From: Honghui Zhang Add the dtsi node of iommu and smi for mt2701. Signed-off-by: Honghui Zhang --- arch/arm/boot/dts/mt2701.dtsi | 51 +++ 1 file changed, 51 insertions(+) diff --git

[PATCH 3/5] memory/mediatek: add support for mt2701

From: Honghui Zhang Mediatek SMI have two generation HW architecture, mt8173 use the secondary generation of SMI HW while mt2701 use the first generation HW of SMI. There's slight differences between the two generation, for generation 2, the register which control

[PATCH 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

From: Honghui Zhang This patch defines the local arbitor port IDs for mediatek SoC MT2701 and add descriptions of binding for mediatek generation one iommu and smi. Signed-off-by: Honghui Zhang ---

[PATCH 0/5] MT2701 iommu support

From: Honghui Zhang Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart Multimedia Interface)have two generations HW. They basically sharing the same hardware block diagram, but have some difference as below: Generation one m4u only support one layer,

[PATCH 2/5] iommu/mediatek: move the common struct into header file

From: Honghui Zhang Move the struct defines of mtk iommu into a new header files for common use. Signed-off-by: Honghui Zhang --- drivers/iommu/mtk_iommu.c | 62 +--- drivers/iommu/mtk_iommu.h | 90

[PATCH 4/5] iommu/mediatek: add support for mtk iommu generation one HW

From: Honghui Zhang Mediatek SoC's M4U have two generations of HW architcture. Generation one use flat, one layer pagetable, and was shipped with ARM architecture, it only support 4K size page mapping. MT2701 SoC use this generation one m4u HW. Generation two uses the

Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain

Hi Chalamarla, On 05/05/2016 09:23 PM, Chalamarla, Tirumalesh wrote: > > > > > > On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger" > eric.au...@linaro.org> wrote: > >> On x86 IRQ remapping is abstracted by the IOMMU.

Re: [PATCH 2/2] iommu/io-pgtable-arm: use __dma_sync_single_for_device()

On Sun, May 08, 2016 at 12:59:56PM +0200, Niklas Söderlund wrote: > The call to dma_sync_single_for_device() can be reached from > dma_map_single(). If CONFIG_DMA_API_DEBUG is enabled this would result > in a check that the mapping being synced is valid. Since the call to > dma_map_single is not

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

Hi Niklas, On 08/05/16 11:59, Niklas Söderlund wrote: Hi, While using CONFIG_DMA_API_DEBUG i came across this warning which I think is a false positive. As shown dma_sync_single_for_device() are called from the dma_map_single() call path. This triggers the warning since the dma-debug code have

Re: [PATCH v2 1/2] PCI: Add PCI device flag PCI_DEV_FLAGS_DMA_ALIAS_ROOT

On 08/05/16 10:33, Jayachandran C via iommu wrote: Add a new flag PCI_DEV_FLAGS_DMA_ALIAS_ROOT to limit the DMA alias search to go no further than the bridge where the IOMMU is attached. This has been added to support Broadcom's Vulcan which has the SMMUv3 and GIC ITS associated with an

Re: [PATCH] iommu/amd: Set AMD iommu callbacks for platform bus driver

On Thu, Apr 14, 2016 at 09:28:53AM -0400, Wan Zongshun wrote: > From: Wan Zongshun > > AMD has more drivers will use ACPI to platform bus driver later, > all those devices need iommu support, such as eMMC acpi driver. > > Signed-off-by: Wan Zongshun >

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On 28/04/2016 17:37, Michael S. Tsirkin wrote: > > All the internally-emulated devices *can* be either translated or > > untranslated. That's just a matter of software. Surely, you currently > > *can't* have translated assigned devices (until someone implements the > > whole VT-d page table

Re: [PATCH 0/5] Introduce per-domain page sizes

On Thu, Apr 07, 2016 at 06:42:03PM +0100, Robin Murphy wrote: > Hi all, > > Since this area seems to be in vogue at the moment, here's what I was > working on when the related patches[1][2] popped up, which happens to > be more or less the intersection of both. As I recycled some of Will's > old

Re: [PATCH V4 0/4] Code refine for Intel IOMMU

On Sun, May 08, 2016 at 01:22:53PM +, Wei Yang wrote: > >Wei Yang (4): > > iommu/vt-d: replace *hdr with {drhd/atsr}[0] in struct > >dmar_{drhd/atsr}_unit > > iommu/vt-d: use zero-sized array in DMAR related ACPI structures > > iommu/vt-d: check Register Base Address at the beginning of

Re: [PATCH 0/5] Introduce per-domain page sizes

Hi Joerg, On 09/05/16 12:21, Joerg Roedel wrote: On Thu, Apr 07, 2016 at 06:42:03PM +0100, Robin Murphy wrote: Hi all, Since this area seems to be in vogue at the moment, here's what I was working on when the related patches[1][2] popped up, which happens to be more or less the intersection

Re: [PATCH 0/5] Introduce per-domain page sizes

On Mon, May 09, 2016 at 12:45:39PM +0100, Robin Murphy wrote: > Thanks a lot! I was expecting to pick this up again after the merge > window and post an updated version then; as you may already have > found, patch 5 conflicts somewhat with the SMMUv2 context format > changes in Will's updates

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On 02/05/2016 20:31, Andy Lutomirski wrote: > And did the SEV implementation remember to encrypt the guest register > state? Because, if not, everything of importance will leak out > through the VMCB and/or GPRs. No, it doesn't. And SEV is very limited unless you paravirtualize everything.

Re: [PATCH 0/5] Introduce per-domain page sizes

On 09/05/16 15:51, Joerg Roedel wrote: On Mon, May 09, 2016 at 12:45:39PM +0100, Robin Murphy wrote: Thanks a lot! I was expecting to pick this up again after the merge window and post an updated version then; as you may already have found, patch 5 conflicts somewhat with the SMMUv2 context

Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

On 5/9/16, 12:48 AM, "Eric Auger" wrote: >Hi Chalarmala, >On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: >> Hi Eric, >> >> Does this series supports gicv3-its emulation? >> Do we have a tree with all the dependent patches >GICv3 ITS emulation support comes

Re: [PATCH 0/5] Introduce per-domain page sizes

On Mon, May 09, 2016 at 04:18:39PM +0100, Robin Murphy wrote: > Bah, I saw last week's "Merge remote-tracking branch > 'will/for-joerg/arm-smmu/updates' into HEAD" commit on that branch > without spotting it was no longer up to date, sorry. Yes, it's > probably safest if I rebase on top of your

Re: [PATCH] iommu/amd: Set AMD iommu callbacks for platform bus driver

On Mon, May 09, 2016 at 08:17:12PM +0800, Wan Zongshun wrote: > Currently, Only New eMMC driver will rely on this sdhci-acpi.c, but > I could not find a suitable ifdef XXX micro to limit this > platform_bus_type here like AMBA bus type before. > > Do you think this MMC_SDHCI_ACPI is ok? Okay,

[PATCH v2] iommu/arm-smmu: Use per-domain page sizes.

Now that we can accurately reflect the context format we choose for each domain, do that instead of imposing the global lowest-common-denominator restriction and potentially ending up with nothing. We currently have a strict 1:1 correspondence between domains and context banks, so we don't need to

[PATCHv6 1/8] dma-mapping: add {map,unmap}_resource to dma_map_ops

Add methods to handle mapping of device resources from a physical address. This is needed for example to be able to map MMIO FIFO registers to a IOMMU. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart ---

[PATCHv6 0/8] dmaengine: rcar-dmac: add iommu support for slave transfers

Hi, This series tries to solve the problem with DMA with device registers (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A recent patch '9575632 (dmaengine: make slave address physical)' clarifies that DMA slave address provided by clients is the physical address. This puts

[PATCHv6 2/8] dma-debug: add support for resource mappings

A MMIO mapped resource can not be represented by a struct page so a new debug type is needed to handle this. This patch add such type and functionality to add/remove entries and how to translate them to a physical address. Signed-off-by: Niklas Söderlund

[PATCHv6 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1

A unconfirmed hardware bug prevents channel 0 and 15 to be used by the DMAC together with the IPMMU. The DMAC driver will disable the channels reducing the effective number of channels to 14 per DMAC. Signed-off-by: Niklas Söderlund Acked-by: Laurent

[PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource

Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops method is available the operation is a no-op. Signed-off-by: Niklas Söderlund --- Documentation/DMA-API.txt | 22 +- include/linux/dma-mapping.h | 36

[PATCHv6 4/8] arm: dma-mapping: add {map, unmap}_resource for iommu ops

Add methods to map/unmap device resources addresses for dma_map_ops that are IOMMU aware. This is needed to map a device MMIO register from a physical address. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCHv6 5/8] dmaengine: rcar-dmac: group slave configuration

Group slave address and transfer size in own structs for source and destination. This is in preparation for hooking up the dma-mapping API to the slave addresses. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCHv6 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers

Enable slave transfers to a device behind a IPMMU by mapping the slave addresses using the dma-mapping API. Signed-off-by: Niklas Söderlund --- drivers/dma/sh/rcar-dmac.c | 82 +- 1 file changed, 74

[PATCHv6 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1

A unconfirmed hardware bug prevents channel 0 and 15 to be used by the DMAC together with the IPMMU. The DMAC driver will disable the channels reducing the effective number of channels to 14 per DMAC. Signed-off-by: Niklas Söderlund Acked-by: Laurent

Re: [PATCH 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

On Mon, May 09, 2016 at 04:00:12PM +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > This patch defines the local arbitor port IDs for mediatek SoC MT2701 and > add descriptions of binding for mediatek generation one iommu and smi. > > Signed-off-by:

Re: [PATCH v9 4/8] iommu/msi-iommu: initialization

On Wed, 4 May 2016 11:40:03 + Eric Auger wrote: > iommu_get/put_msi_cookie allocates/frees the resource used to store > and ref count the MSI doorbell mappings. iommu_msi_set_aperture > initializes the iova domain used for MSI IOVA allocation and sets the > iommu

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On 05/09/2016 10:13 AM, Paolo Bonzini wrote: > > > On 02/05/2016 20:31, Andy Lutomirski wrote: >> And did the SEV implementation remember to encrypt the guest register >> state? Because, if not, everything of importance will leak out >> through the VMCB and/or GPRs. > > No, it doesn't. And

Re: [PATCH V4 0/4] Code refine for Intel IOMMU

On Mon, May 09, 2016 at 01:24:02PM +0200, Joerg Roedel wrote: >On Sun, May 08, 2016 at 01:22:53PM +, Wei Yang wrote: >> >Wei Yang (4): >> > iommu/vt-d: replace *hdr with {drhd/atsr}[0] in struct >> >dmar_{drhd/atsr}_unit >> > iommu/vt-d: use zero-sized array in DMAR related ACPI

Re: [PATCH v9 2/7] vfio/type1: vfio_find_dma accepting a type argument

On Wed, 4 May 2016 11:54:13 + Eric Auger wrote: > In our RB-tree we now have slots of different types (USER and RESERVED). > It becomes useful to be able to search for dma slots of a specific type or > any type. This patch proposes an implementation for that modality

Re: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots

On Wed, 4 May 2016 11:54:14 + Eric Auger wrote: > Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots, > let's implement the expected behavior for removal and replay. As opposed > to user dma slots, IOVAs are not systematically bound to PAs and PAs are

Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain

On Wed, 4 May 2016 11:54:16 + Eric Auger wrote: > On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted > by the msi controller. vfio_safe_irq_domain allows to check whether > interrupts are "safe" for a given device. They are if the device does >

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

On Wed, 4 May 2016 11:54:18 + Eric Auger wrote: > This patch allows the user-space to retrieve the MSI geometry. The > implementation is based on capability chains, now also added to > VFIO_IOMMU_GET_INFO. > > The returned info comprise: > - whether the MSI IOVA are

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

On Wed, 4 May 2016 14:06:19 +0200 Eric Auger wrote: > Hi Alex, > On 05/04/2016 01:54 PM, Eric Auger wrote: > > This patch allows the user-space to retrieve the MSI geometry. The > > implementation is based on capability chains, now also added to > > VFIO_IOMMU_GET_INFO.

Re: [PATCH 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

On 5/10/2016 4:22 AM, Rob Herring wrote: > On Mon, May 09, 2016 at 04:00:12PM +0800, honghui.zh...@mediatek.com wrote: >> From: Honghui Zhang >> >> This patch defines the local arbitor port IDs for mediatek SoC MT2701 and >> add descriptions of binding for mediatek