Hi Robin,
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Robin Murphy
> Sent: 26 January 2016 23:37
> To: will.dea...@arm.com
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.or
This patch adds info about 'smmu-inst-as-data' DT option in ARM
SMMUv1/SMMUv2 driver bindings document.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Vikram Prakash
Reviewed-by: Scott Branden
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8
1 file changed,
From: Sricharan R
This patch uses IOMMU_OF_DECLARE to register the driver
and the iommu_ops. So when master devices of the iommu are
registered, of_xlate callback can be used to add the master
configurations to the smmu driver.
Signed-off-by: Sricharan R
Signed-off-by: Anup Patel
Tested-by: An
Currently, the SMMU driver by default provides unprivilege read-write
permission in page table entries of stage1 page table. For SMMUv2 with
aarch64 long descriptor format, a privilege instruction fetch will
generate context fault. To allow privilege instruction fetch from a
MMU master we need to t
We are saving pointer to iommu DT node in of_iommu_set_ops()
hence we should increment DT node ref count.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/iommu/of_iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/of_iommu.c b/driver
The SMMUv1/SMMUv2 driver is initialized very early using the
IOMMU_OF_DECLARE() but the actual platform device is probed
via normal DT probing.
This patch uses of_platform_device_create() from arm_smmu_of_setup()
to ensure that SMMU platform device is probed immediately.
Signed-off-by: Anup Patel
This patchset adds following to SMMUv1/SMMUv2 driver:
1. Support for domain type IOMMU_DOMAIN_DMA
2. Allow privilege instruction fetchs from MMU masters by having
a DT option to treat instruction fetch as data read
The patchset is based on '4.5-rc1' tag of linux mainline tree
and is available in s
To allow use of large memory (> 4Gb) with 32bit devices we need to use
some kind of iommu for such 32bit devices.
This patch extends SMMUv1/SMMUv2 driver to support DMA domains which
in-turn will allows us to use iommu based DMA mappings for 32bit devices.
Signed-off-by: Anup Patel
Reviewed-by:
On Tue, Jan 26, 2016 at 12:12:39PM +0800, Yong Wu wrote:
> This patch add smi binding document and smi local arbiter header file.
>
> Signed-off-by: Yong Wu
> ---
> .../memory-controllers/mediatek,smi-common.txt | 24 +
> .../memory-controllers/mediatek,smi-larb.txt | 25 +
>
/MT8173-IOMMU-SUPPORT/20160126-201633
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
On Wed, 2016-01-20 at 14:46 +, Robin Murphy wrote:
> > Of course, the 0.004014s maybe not accurate enough, it is just an
> > approximate number.
>
> A mean and standard deviation of at least, say, 5 runs each with and
> without the patch would be considerably more meaningful (even if
> still
Hello!
I'd like just to clarify some things for myself and better wrap my head around
it...
> On x86 all accesses to the 1MB PA region [FEE0_h - FEF0_000h] are directed
> as interrupt messages: accesses to this special PA window directly target the
> APIC configuration space and not DRAM, m
-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01270003 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `vfio_reserved_binding_r
TLB synchronisation is a mighty big hammmer to bring down on the
transaction stream, typically stalling all in-flight transactions until
the sync completes. Since in most cases (except at stage 2 on SMMUv1)
a per-context sync operation is available, prefer that over the global
operation when perfor
Borrow the disable_bypass parameter from the SMMUv3 driver as a handy
debugging/security feature so that unmatched stream IDs (i.e. devices
not attached to an IOMMU domain) may be configured to fault.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 32 +++-
The IOMMU API has no concept of privilege so assumes all devices and
mappings are equal, and indeed most non-CPU master devices on an AMBA
interconnect make little use of the attribute bits on the bus thus by
default perform unprivileged data accesses.
Some devices, however, believe themselves mor
With DMA mapping ops provided by the iommu-dma code, only a minimal
contribution from the IOMMU driver is needed to create a suitable
DMA-API domain for them to use. Implement this for the ARM SMMUs.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c | 10 +-
drivers/iommu/arm-s
Hi Will,
Here's my current "miscellaneous SMMU enhancements" branch for your
consideration. Patch #1 solves a subtle corner case that cropped up
while exercising stage 1 context formats on the DMA330-MMU500 model;
#3 will be wanted fairly soon for DMA ops integration so may as well
get some exposu
On 26/01/16 04:12, Yong Wu wrote:
This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).
Whilst I can't speak for the hardware specifics, I think we've got the
API aspects and general shape of the code looking pretty much right by
now - I don't see anything worth compla
Add some simple wrappers to avoid having the guts of the TLB operations
spilled all over the page table implementations, and to provide a point
to implement extra common functionality.
Acked-by: Will Deacon
Acked-by: Laurent Pinchart
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm
Hi all,
As promised, here's v3 based on 4.5-rc1, with all the previous comments
addressed other than the logic of split_blk_unmap() - having looked into
it, trying to simplify that essentially just pushes the complexity out
into map() and complicates the general case. Ultimately it's an awkward
ed
In certain unmapping situations it is quite possible to end up issuing
back-to-back TLB synchronisations, which at best is a waste of time and
effort, and at worst causes some hardware to get rather confused. Whilst
the pagetable implementations, or the IOMMU drivers, or both, could keep
track of t
Add a nearly-complete ARMv7 short descriptor implementation, omitting
only a few legacy and CPU-centric aspects which shouldn't be necessary
for IOMMU API use anyway.
Signed-off-by: Yong Wu
Signed-off-by: Robin Murphy
---
drivers/iommu/Kconfig | 19 +
drivers/iommu/Makefile
-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01262306 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
ERROR: "alloc_iova" [drivers/vfio/vfio_iommu_typ
the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
> config: x86_64-randconfig-s3-01262306 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> m
Looks like the VT-D spec at intel.com got moved.
Update the link.
Signed-off-by: Michael S. Tsirkin
---
Documentation/Intel-IOMMU.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/Intel-IOMMU.txt b/Documentation/Intel-IOMMU.txt
index 7b57fc0..49585b6 100644
--
-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01262306 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "alloc_iova" [drivers/vfio/vfio_iom
From: Wan Zongshun
AMD Uart DMA belongs to ACPI HID type device, and its driver
is basing on AMBA Bus, need also IOMMU support.
This patch is just to set the AMD iommu callbacks for amba bus.
Signed-off-by: Wan Zongshun
---
drivers/iommu/amd_iommu.c | 13 -
1 file changed, 12 inse
From: Wan Zongshun
This patch is to make the call-sites of get_device_id aware of its
return value.
Signed-off-by: Wan Zongshun
---
drivers/iommu/amd_iommu.c | 51 +--
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/amd_
From: Wan Zongshun
This patch creates a new function for finding or creating an IOMMU
group for acpihid(ACPI Hardware ID) device.
The acpihid devices with the same devid will be put into same group and
there will have the same domain id and share the same page table.
Signed-off-by: Wan Zongshun
From: Wan Zongshun
Current IOMMU driver make assumption that the downstream devices are PCI.
With the newly added ACPI-HID IVHD device entry support, this is no
longer true. This patch is to add dev type check and to distinguish the
pci and acpihid device code path.
Signed-off-by: Wan Zongshun
From: Suravee Suthikulpanit
The IVRS in more recent AMD system usually contains multiple
IVHD block types (e.g. 0x10, 0x11, and 0x40) for each IOMMU.
The newer IVHD types provide more information (e.g. new features
specified in the IOMMU spec), while maintain compatibility with
the older IVHD typ
From: Wan Zongshun
This patch introduces acpihid_map, which is used to store
the new IVHD device entry extracted from BIOS IVRS table.
It also provides a utility function add_acpi_hid_device(),
to add this types of devices to the map.
Signed-off-by: Wan Zongshun
Signed-off-by: Suravee Suthikul
From: Wan Zongshun
There are some devices indentified using ACPI HID format in AMD chip.
This patch series enable iommu support for those ACPI HID device,
since the existing AMD iommu only supports PCI bus based device.
The latest public version of AMD IOMMU specification that describes
the sup
From: Suravee Suthikulpanit
This patch introduces a new kernel parameter, ivrs_acpihid.
This is used to override existing ACPI-HID IVHD device entry,
or add an entry in case it is missing in the IVHD.
Signed-off-by: Wan Zongshun
Signed-off-by: Suravee Suthikulpanit
---
Documentation/kernel-pa
From: Suravee Suthikulpanit
This patch modifies the existing struct ivhd_header, which currently
only support IVHD type 0x10, to add new fields from IVHD type 11h and 40h.
It also modifies the pointer calculation to allow support for IVHD type
11h and 40h
Signed-off-by: Suravee Suthikulpanit
--
-IOMMU-SUPPORT/20160126-201633
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm64-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod
the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
> config: i386-allmodconfig (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i38
-passthrough-on-ARM-ARM64/20160126-211921
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/vfio/pci/vfio_pci_intrs.c: In function 'vfio_set_mapp
The user is allowed to register a reserved IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
It provides the base address and the size. This region is stored in the
vfio_dma rb tree. At that point the iova range is not mapped to any target
address ye
This new function enables to know whether msi write transaction
addresses must be mapped.
Signed-off-by: Eric Auger
---
drivers/vfio/vfio.c | 22 ++
drivers/vfio/vfio_iommu_type1.c | 8
include/linux/vfio.h| 2 ++
3 files changed, 32 inserti
Add a new set_group operation which allows to cache the vfio_group
handle within the vfio_pci_device struct. This is useful to do
iommu operations from the vfio_pci device.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 8
drivers/vfio/pci/vfio_pci_private.h | 1 +
Some platforms require the MSI address programmed in the PCI
device to be an IOVA and not a host physical address.
This is typically the case for ARM and PowerPC, as opposed
to x86. This patch allocates an IOVA page and maps it onto
the physical page which contains the target MSI write transaction
We introduce a vfio_dma type since we will need to discriminate
legacy vfio_dma's from new reserved ones. Since those latter are
not mapped at registration, some handlings must be unplugged:
removal, replay. They will be enhanced later on.
Signed-off-by: Eric Auger
---
drivers/vfio/vfio_iommu_ty
Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported,
this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS
and FSL PAMU, at least expose this attribute.
x86 IOMMUs typically don't expose the attribute since on x86 MSI write
transaction addresses always are within
Legacy dma_list is just used to insert the reserved iova region and
check mapping of reserved iova happens in this window. As opposed to
other vfio_dma slots, the reserved one is not necessarily mapped.
We will need to track which host physical addresses are mapped to
reserved IOVA. In that prospe
This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
It pursues the efforts done on [1], [2], [3]. It also aims at covering the
same need on some PowerPC platforms.
On x86 all accesses to the 1MB PA region [FEE0_h - FEF0_000h] are directed
as interrupt messages: accesses t
This patch allows the user-space to retrieve whether msi write
transaction addresses must be mapped. This is returned through the
VFIO_IOMMU_GET_INFO API using a new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.
Signed-off-by: Bharat Bhushan
Signed-off-by: Eric Auger
---
RFC v1 -> RFC v2:
- derived f
This patch adds a reserved iova_domain to the vfio_domain struct.
This iova domain will enable to allocate iova within the reserved
iova region.
alloc_reserved_iova_domain makes possible to allocate and initialize
this iova domain. The user will be introduced in subsequent patches.
Signed-off-by:
This patch introduces vfio_group_alloc_map_/unmap_free_reserved_iova
and implements corresponding vfio_iommu_type1 operations.
alloc_map allows to allocate a new reserved iova page and map it
onto the physical page that contains a given PA. It returns the iova
that is mapped onto the provided PA.
This patch add the iommu/larbs nodes for mt8173
Signed-off-by: Yong Wu
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ec1
This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the power domain
and clocks of each local arbiter.
Signed-off-by: Yong Wu
Tested-by: Philipp Zabel
---
drivers/memory/Kconfig | 8 ++
drivers/memory/Makefile| 1 +
d
This patch add smi binding document and smi local arbiter header file.
Signed-off-by: Yong Wu
---
.../memory-controllers/mediatek,smi-common.txt | 24 +
.../memory-controllers/mediatek,smi-larb.txt | 25 +
include/dt-bindings/memory/mt8173-larb-port.h | 111 +
This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).
Signed-off-by: Yong Wu
---
drivers/iommu/Kconfig | 16 +
drivers/iommu/Makefile| 1 +
drivers/iommu/mtk_iommu.c | 732 ++
3 files changed, 749 insertions(+)
creat
This patch add mediatek iommu dts binding document.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
d
This patch set adds support for m4u(Multimedia Memory Management Unit),
Currently it only support the m4u with 2 levels of pagetable on mt8173.
It's also based on Robin Murphy's reposting Short-descriptor v2.
Please check the hardware block diagram of Mediatek IOMMU.
m4u (M
On Tue, Jan 26, 2016 at 03:11:27AM +, Chalamarla, Tirumalesh wrote:
> one my colleague points out, ASIDPNE also implementation defined.
It looks pretty well defined to me, despite being a hint:
This ASIDPNE indication is only a hint, and an SMMU can ignore it. In
particular, if the SMMU
On 26/01/16 03:11, Chalamarla, Tirumalesh wrote:
one my colleague points out, ASIDPNE also implementation defined.
ASIDPNE only covers whether the SMMU's TLBs may ignore broadcast
_invalidation_ or not, not lookups. Broadcast TLB lookups are not a thing.
Thanks,
Tirumalesh.
On 1/25/16, 4
CC more people who is interested
On 01/26/16 at 06:29pm, Baoquan He wrote:
> This is v3 post. Now the situation is patchset test on amd-vi v2 machine
> is OK, however still some IO_PAGE_FAULT warning is printed out on v1
> machine. The log will be attached later.
>
> I didn't figure out what caus
This one has been posted, so can be ignored here.
On 01/26/16 at 06:29pm, Baoquan He wrote:
> Signed-off-by: Baoquan He
> ---
> drivers/iommu/amd_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index dda703
In amd-vi spec bit[60:58] are only used to store the bit[14:12] of GCR3.
No any other useage is found in several versions of amd-vi spec. So remove
them in this patch.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 6 +++---
drivers/iommu/amd_iommu_types.h | 2 --
2 files change
Don't update the domain information to the related DTE entry before
iommu dev initialization. For this a new member 'domain_updated' is
added to iommu_dev_data.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --gi
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index dda703b..02c6ed9 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2051,7 +2051,7 @@ sta
Whatever it does to initialize dev to alloc coherent memory or map allocated
memory to io addr __map_single need be called. So update the related domain
information to its DTE entry and alias when __map_single is firstly called.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 11 ++
Here several things need be done:
1) Initialize amd_iommu_dev_table because it was set several times
since kdump kernel reboot. We don't need the set because we will
copy the content from old kernel.
2) Re-enable event/cmd buffer
3) Install the DTE table to reg
4) Flush all caches
Signed-off-by: B
Add function copy_dev_tables to copy old DTE in 1st kernel to
the new DTE table. Since all iommu share the same DTE table the
copy only need be done once as long as the physical address of
old DTE table is retrieved from iommu reg. Besides the old domain
id occupied in 1st kernel need be reserved i
This is a clean up. In get_irq_table() only if DTE entry is changed
iommu_completion_wait() need be called. Otherwise no need to do it.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/dr
In amd-vi spec the name of bit0 in DTE is V. But in code it's defined
as IOMMU_PTE_P. Here change it to IOMMU_PTE_V to make it be consistent
with spec.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 10 +-
drivers/iommu/amd_iommu_types.h | 6 +++---
2 files changed, 8 i
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 26 ++
drivers/iommu/amd_iommu_proto.h | 4
2 files changed, 30 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init.c b/drive
If irq table exists in old kernel create a new one and copy the content
of old irq table to the newly created.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 43 +
drivers/iommu/amd_iommu_proto.h |
These macro definitions are also needed by irq table copy function
later, so move them to amd_iommu_types.h.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 4
drivers/iommu/amd_iommu_types.h | 5 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/i
It will be more readable then the old setting.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 539b0de..dd869fe
This is v3 post. Now the situation is patchset test on amd-vi v2 machine
is OK, however still some IO_PAGE_FAULT warning is printed out on v1
machine. The log will be attached later.
I didn't figure out what caused the warning, so post them to ask for help.
The strategy is unchanged:
1) Copy old
73 matches
Mail list logo
