Right now, the tlb_add_flush_nosync and tlb_sync always appear together.
we merge the two functions into one(also move the tlb_lock into the new
function). No functional change.
Signed-off-by: Chao Hao
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 45 ++-
In our tlb range flush, we don't care the "leaf". Remove it to simplify
the code. no functional change.
"granule" also is unnecessary for us, Keep it satisfy the format of
tlb_flush_walk.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/mtk_iommu.c | 21 -
Use the iommu_gather mechanism to achieve the tlb range flush.
Gather the iova range in the "tlb_add_page", then flush the merged iova
range in iotlb_sync.
Suggested-by: Tomasz Figa
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 12
1 file changed, 8 insertions(+), 4 deleti
Now we have tlb_lock for the HW tlb flush, then pgtable code hasn't
needed the external "pgtlock" for a while. this patch remove the
"pgtlock".
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/driv
Reduce the tlb timeout value from 10us to 1000us. the original value
is so long that affect the multimedia performance. This is only a minor
improvement rather than fixing a issue.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
The commit 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API
TLB sync") help move the tlb_sync of unmap from v7s into the iommu
framework. It helps add a new function "mtk_iommu_iotlb_sync", But it
lacked the lock, then it will cause the variable "tlb_flush_active"
may be changed unexpe
This patchset mainly fixes a tlb flush timeout issue and use the new
iommu_gather to re-implement the tlb flush flow. and several clean up
patches about the tlb_flush.
change note:
v4: 1. Add a new tlb_lock for tlb operations.
2. Delete the pgtlock.
3. Remove the "writel" patch.
v3:
htt
Use the correct tlb_flush_all instead of the original one.
Fixes: 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB sync")
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i
Hi,
On 10/15/19 11:11 PM, Yuri Volchkov wrote:
For health monitoring, it can be useful to know if iommu is behaving as
expected. DMAR faults can be an indicator that a device:
- has been misconfigured, or
- has experienced a hardware hiccup and replacement should
be considered, or
- ha
Hi,
On 10/16/19 12:49 AM, Yian Chen wrote:
VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
for device use only and should not be part of allocable memory pool of OS.
BIOS e820_table reports complete memory map to OS, including OS usable
memory ranges and BIOS reserved memory r
VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
for device use only and should not be part of allocable memory pool of OS.
BIOS e820_table reports complete memory map to OS, including OS usable
memory ranges and BIOS reserved memory ranges etc.
x86 BIOS may not be trusted to inc
[+cc Jerry]
On Wed, Oct 09, 2019 at 05:45:49PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> I think intel-iommu.c depends on CONFIG_AMD_IOMMU in an undesirable way:
>
> When CONFIG_INTEL_IOMMU_SVM=y, iommu_enable_dev_iotlb() calls PRI
> interfaces (pci_reset_pri() and pci_enable_pri())
On Wed, Oct 09, 2019 at 05:53:51PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Most of the ATS/PRI/PASID interfaces are only used by IOMMU drivers that
> can only be built statically, not as modules. A couple are only used by
> the PCI core and don't need to be visible outside at all.
Am Mittwoch, 2. Oktober 2019, 19:29:23 CEST schrieb Ezequiel Garcia:
> IOMMU domain resource life is well-defined, managed
> by .domain_alloc and .domain_free.
>
> Therefore, domain-specific resources shouldn't be tied to
> the device life, but instead to its domain.
>
> Signed-off-by: Ezequiel G
Hi John,
On 30/09/2019 15:33, John Garry wrote:
This patchset adds IMP DEF event support for the SMMUv3 PMCG.
It is marked as an RFC as the method to identify the PMCG implementation
may be a quite disliked. And, in general, the series is somewhat
incomplete.
So the background is that the PMCG
On Tue, Oct 15, 2019 at 09:48:22AM +0200, Nicolas Saenz Julienne wrote:
> A little off topic but I was wondering if you have a preferred way to refer to
> the arm architecture in a way that it unambiguously excludes arm64 (for
> example
> arm32 would work).
arm32 should be fine. Neither arm64 nor
From: Thierry Reding
Registering as memory controller allows other drivers to obtain a
reference to it. This is mostly useful as a way of ordering probe
between devices depending on one another.
Signed-off-by: Thierry Reding
---
drivers/memory/tegra/tegra186.c | 8 +++-
1 file changed, 7 i
From: Thierry Reding
Use the memory controller framework to obtain a reference to the memory
controller to which the SMMU will make memory requests. This allows the
two drivers to properly order their probes so that the memory controller
can be programmed first.
An example where this is required
From: Thierry Reding
This new framework is currently nothing more than a registry of memory
controllers, with the goal being to order device probing. One use-case
where this is useful, for example, is a memory controller device which
needs to program some registers before the system MMU can be en
From: Thierry Reding
Hi,
this series proposes the introduction of a mini-framework for memory
controllers. The primary use-case for this right now is to allow for
drivers that depend on the memory controller to defer probe until the
memory controller has been successfully registered.
One exampl
On 2019-10-15 7:37 a.m., Joerg Roedel wrote:
> On Tue, Oct 08, 2019 at 04:18:37PM -0600, Logan Gunthorpe wrote:
>> -static struct irq_remap_table *alloc_irq_table(u16 devid)
>> +static int set_remap_table_entry_alias(struct pci_dev *pdev, u16 alias,
>> + void *d
On 14/10/2019 11:10, Thomas Gleixner wrote:
> On Mon, 14 Oct 2019, Guilherme G. Piccoli wrote:
>> Modules linked in: <...>
>> CPU: 40 PID: 78274 Comm: qemu-system-x86 Tainted: P W OE
>
> Tainted: P - Proprietary module loaded ...
>
> Try again without that module
Thanks Thomas, for the prom
First dmar faults can happen even before linux have scanned PCI
bus. In such case worker will not have chance to lookup a
corresponding 'struct pci_dev'.
This commit defers processing of the fault until intel_iommu_init
function has been called. At this point of time pci devices will be
already in
For health monitoring, it can be useful to know if iommu is behaving as
expected. DMAR faults can be an indicator that a device:
- has been misconfigured, or
- has experienced a hardware hiccup and replacement should
be considered, or
- has been issuing faults due to malicious activity
Curre
Currently dmar_fault handler only prints a message in the dmesg. This
commit introduces counters - how many faults have happened, and
exposes them via sysfs. Each pci device will have an entry
'dmar_faults' reading from which will give user 3 lines
remap: xxx
read: xxx
write: xxx
This functi
On Tue, Oct 08, 2019 at 04:18:37PM -0600, Logan Gunthorpe wrote:
> -static struct irq_remap_table *alloc_irq_table(u16 devid)
> +static int set_remap_table_entry_alias(struct pci_dev *pdev, u16 alias,
> +void *data)
> +{
> + struct irq_remap_table *table = da
Il giorno mar 15 ott 2019 alle ore 14:40 Joerg Roedel
ha scritto:
>
> On Tue, Oct 15, 2019 at 02:33:47PM +0200, AngeloGioacchino Del Regno wrote:
> > Il giorno mar 15 ott 2019 alle ore 13:14 Joerg Roedel
> > ha scritto:
> > >
> > > On Wed, Oct 02, 2019 at 12:01:59AM +0200, khol...@gmail.com wrote
On Tue, 2019-10-15 at 03:23 -0700, Christoph Hellwig wrote:
> On Mon, Oct 14, 2019 at 08:31:06PM +0200, Nicolas Saenz Julienne wrote:
> > The Raspberry Pi 4 has a 1GB ZONE_DMA area starting at address
> > 0x and a mapping between physical and DMA memory offset by
> > 0xc000. It transpi
Il giorno mar 15 ott 2019 alle ore 14:10 Robin Murphy
ha scritto:
>
> On 01/10/2019 23:02, khol...@gmail.com wrote:
> > From: AngeloGioacchino Del Regno
> >
> > As specified in this driver, the context banks are 0x1000 apart.
> > Problem is that sometimes the context number (our asid) does not
>
On Tue, Oct 15, 2019 at 02:33:47PM +0200, AngeloGioacchino Del Regno wrote:
> Il giorno mar 15 ott 2019 alle ore 13:14 Joerg Roedel
> ha scritto:
> >
> > On Wed, Oct 02, 2019 at 12:01:59AM +0200, khol...@gmail.com wrote:
> > > From: "Angelo G. Del Regno"
> > >
> > > Add a function to change the I
Il giorno mar 15 ott 2019 alle ore 13:14 Joerg Roedel
ha scritto:
>
> On Wed, Oct 02, 2019 at 12:01:59AM +0200, khol...@gmail.com wrote:
> > From: "Angelo G. Del Regno"
> >
> > Add a function to change the IOMMU pagetable addressing to
> > AArch32 LPAE or AArch64. If doing that, then this must be
On Wed, Oct 09, 2019 at 07:59:33PM +0800, Yong Wu wrote:
> In the commit 4f0a1a1ae351 ("memory: mtk-smi: Invoke pm runtime_callback
> to enable clocks"), we use pm_runtime callback to enable/disable the smi
> larb clocks. It will cause the larb's clock may not be disabled when
> suspend. That is be
On Mon, Oct 14, 2019 at 08:06:19PM +, Suthikulpanit, Suravee wrote:
> Reuse existing macro to simplify the code and improve readability.
>
> Cc: Joerg Roedel
> Cc: Gary R Hook
> Signed-off-by: Suravee Suthikulpanit
> ---
> drivers/iommu/amd_iommu.c | 3 +--
> 1 file changed, 1 insertion(+)
On Mon, Oct 14, 2019 at 08:06:05PM +, Suthikulpanit, Suravee wrote:
> IOMMU Event Log encodes 20-bit PASID for events:
> ILLEGAL_DEV_TABLE_ENTRY
> IO_PAGE_FAULT
> PAGE_TAB_HARDWARE_ERROR
> INVALID_DEVICE_REQUEST
> as:
> PASID[15:0] = bit 47:32
> PASID[19:16] = bit 19:16
On 01/10/2019 23:02, khol...@gmail.com wrote:
From: AngeloGioacchino Del Regno
As specified in this driver, the context banks are 0x1000 apart.
Problem is that sometimes the context number (our asid) does not
match this logic and we end up using the wrong one: this starts
being a problem in the
Hey Bjorn,
On Wed, Oct 09, 2019 at 05:45:49PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> I think intel-iommu.c depends on CONFIG_AMD_IOMMU in an undesirable way:
>
> When CONFIG_INTEL_IOMMU_SVM=y, iommu_enable_dev_iotlb() calls PRI
> interfaces (pci_reset_pri() and pci_enable_pri()),
On 02/10/2019 18:29, Ezequiel Garcia wrote:
IOMMU domain resource life is well-defined, managed
by .domain_alloc and .domain_free.
Therefore, domain-specific resources shouldn't be tied to
the device life, but instead to its domain.
FWIW,
Reviewed-by: Robin Murphy
Signed-off-by: Ezequiel G
Hi Bjorn,
On Wed, Oct 09, 2019 at 05:53:51PM -0500, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Most of the ATS/PRI/PASID interfaces are only used by IOMMU drivers that
> can only be built statically, not as modules. A couple are only used by
> the PCI core and don't need to be visible outsi
On Fri, Oct 04, 2019 at 09:55:54PM +0100, Chris Wilson wrote:
> [2.073922] DMAR: ACPI device "INT33C2:00" under DMAR at fed91000 as
> 00:15.1
> [2.073983] DMAR: ACPI device "INT33C3:00" under DMAR at fed91000 as
> 00:15.2
> [2.074027] DMAR: ACPI device "INT33C0:00" under DMAR at fed91
On 15/10/2019 06:26, Yong Wu wrote:
On Mon, 2019-10-14 at 15:21 +0100, Robin Murphy wrote:
On 14/10/2019 07:38, Yong Wu wrote:
Use the iommu_gather mechanism to achieve the tlb range flush.
Gather the iova range in the "tlb_add_page", then flush the merged iova
range in iotlb_sync.
Note: If io
On Wed, Oct 02, 2019 at 12:42:39PM -0700, Jacob Pan wrote:
> Jacob Pan (2):
> iommu/ioasid: Add custom allocators
> iommu: Introduce guest PASID bind function
>
> Jean-Philippe Brucker (1):
> iommu: Add I/O ASID allocator
>
> Yi L Liu (1):
> iommu: Introduce cache_invalidate API
>
> dri
On 15/10/2019 06:25, Yong Wu wrote:
On Mon, 2019-10-14 at 15:22 +0100, Robin Murphy wrote:
On 14/10/2019 07:38, Yong Wu wrote:
In our tlb range flush, we don't care the "leaf". Remove it to simplify
the code. no functional change.
Presumably you don't care about the granule either?
Yes. I o
On Wed, Oct 02, 2019 at 02:29:23PM -0300, Ezequiel Garcia wrote:
> IOMMU domain resource life is well-defined, managed
> by .domain_alloc and .domain_free.
>
> Therefore, domain-specific resources shouldn't be tied to
> the device life, but instead to its domain.
>
> Signed-off-by: Ezequiel Garci
On Wed, Oct 02, 2019 at 12:01:59AM +0200, khol...@gmail.com wrote:
> From: "Angelo G. Del Regno"
>
> Add a function to change the IOMMU pagetable addressing to
> AArch32 LPAE or AArch64. If doing that, then this must be
> done for each IOMMU context (not necessarily at the same time).
This patch
To support different registers memory mapping hardware easily
in the future, this patch removes all unused register
definitions.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 76 --
1 file changed, 76 deletions(-)
diff --git a/driv
Since we will have changed memory mapping of the IPMMU in the future,
This patch adds helper functions ipmmu_utlb_reg() and
ipmmu_imu{asid,ctr}_write() for "uTLB" registers. No behavior change.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 26 +-
1 fil
Since we will have changed memory mapping of the IPMMU in the future,
This patch adds helper functions ipmmu_ctx_{reg,read,write}()
for MMU "context" registers. No behavior change.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 32 +++-
1 file chang
This patch series is based on the latest iommu.git / next branch
to modify the driver in the future's new hardware.
Changes from v1:
- Remove all unused register definitions instead of selective.
so that I didn't add Geert-san's Reviewed-by in the patch [1/3].
- To improve code readability, a
To support different registers memory mapping hardware easily
in the future, this patch tidies up the register definitions
as below:
- Add comments to state to which SoCs or SoC families they apply
- Add categories about MMU "context" and uTLB registers
No change behavior.
Signed-off-by: Yoshih
Since we will have changed memory mapping of the IPMMU in the future,
this patch uses ipmmu_features values instead of a macro to
calculate context registers offset. No behavior change.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 11 ---
1 file changed, 8 insertions
Since we will have changed memory mapping of the IPMMU in the future,
this patch adds a utlb_offset_base into struct ipmmu_features
for IMUCTR and IMUASID registers. No behavior change.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 5 -
1 file changed, 4 insertions(+), 1
On Tue, Oct 01, 2019 at 08:06:22PM +0200, Geert Uytterhoeven wrote:
> As platform_get_irq() now prints an error when the interrupt does not
> exist, calling it gratuitously causes scary messages like:
>
> ipmmu-vmsa e674.mmu: IRQ index 0 not found
>
> Fix this by moving the call to platfo
On Fri, Sep 27, 2019 at 11:53:21AM +0100, Biju Das wrote:
> Support RZ/G2N (R8A774B1) IPMMU.
>
> Signed-off-by: Biju Das
> Reviewed-by: Geert Uytterhoeven
> ---
> V1-->V2
> * Incorporated Geet's review comment
> * Added Geert's Reviewed-by tag
> ---
> drivers/iommu/ipmmu-vmsa.c | 5 +
>
On Wed, Sep 25, 2019 at 08:43:46PM +0200, Heiko Stuebner wrote:
> Till now the Rockchip iommu driver walked through the irq list via
> platform_get_irq() until it encountered an ENXIO error. With the
> recent change to add a central error message, this always results
> in such an error for each iom
On Mon, Oct 14, 2019 at 08:31:06PM +0200, Nicolas Saenz Julienne wrote:
> The Raspberry Pi 4 has a 1GB ZONE_DMA area starting at address
> 0x and a mapping between physical and DMA memory offset by
> 0xc000. It transpires that, on non LPAE systems, any attempt to
> translate physical a
I think we just need to byte the bullet and move over arm to dma-direct
entirely. This needs a careful audit of what differs, but the biggest
item is that we need to ensure dmabounce keeps working (or is replaced
with swiotlb in a suitable way, but that might be a lot more work).
_
On Tue, Sep 24, 2019 at 08:40:54AM +0100, Biju Das wrote:
> Document RZ/G2N (R8A774B1) SoC bindings.
>
> Signed-off-by: Biju Das
> ---
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
On Sat, Sep 21, 2019 at 03:06:44PM +0800, Lu Baolu wrote:
> Current find_domain() helper checks and does the deferred domain
> attachment and return the domain in use. This isn't always the
> use case for the callers. Some callers only want to retrieve the
> current domain in use.
>
> This refacto
On Mon, Sep 16, 2019 at 10:29:36PM +0200, Christophe JAILLET wrote:
> 'iommu_group_get_for_dev()' never returns NULL, so this test can be
> simplified a bit.
>
> This way, the test is consistent with all other calls to
> 'iommu_group_get_for_dev()'.
>
> Signed-off-by: Christophe JAILLET
> ---
>
Hi Hanjun,
Thanks for checking this.
*/
static int __init iort_add_platform_device(struct acpi_iort_node *node,
- const struct iort_dev_config *ops)
+ const struct iort_dev_config *ops,
struct device *parent)
On 15/10/2019 04:06, Hanjun Guo wrote:
-/*
> - * PMCG model identifiers for use in smmu pmu driver. Please note
> - * that this is purely for the use of software and has nothing to
> - * do with hardware or with IORT specification.
> - */
> -#define IORT_SMMU_V3_PMCG_GENERIC0x /*
Hi,
On 10/2/19 9:42 PM, Jacob Pan wrote:
> This set consists of IOMMU APIs to support SVA in the guest, a.k.a nested
> SVA. As the complete SVA support is complex, we break down the enabling
> effort into three stages:
> 1. PCI device direct assignment
> 2. Fault handling, especially page request
On Mon, Oct 14, 2019 at 10:14:05AM -0700, Jacob Pan wrote:
> Hi Joerg,
>
> Just another gentle reminder. I think we have reached consensus in this
> common code. Jean and Eric can confirm.
Yes for the whole series
Reviewed-by: Jean-Philippe Brucker
_
On Mon, 2019-10-14 at 21:59 +0100, Catalin Marinas wrote:
> On Mon, Oct 14, 2019 at 08:31:02PM +0200, Nicolas Saenz Julienne wrote:
> > the Raspberry Pi 4 offers up to 4GB of memory, of which only the first
> > is DMA capable device wide. This forces us to use of bounce buffers,
> > which are curre
On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
> From: Thiago Jung Bauermann
>
> Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
> be set by both device and guest driver. However, as a hack, when DMA API
> returns physical addresses, guest driver can use the DM
On Mon, Oct 14, 2019 at 11:29:24AM +0100, Robin Murphy wrote:
>> However, I would like to see the commit message (and maybe the inline
>> comments) expanded a bit on what the distinction here is about. Some
>> of the text from the next patch would be suitable, about DMA addresses
>> usually being
On Mon, Oct 14, 2019 at 11:29:24AM +0100, Robin Murphy wrote:
> On 14/10/2019 05:51, David Gibson wrote:
> >On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote:
> >>From: Thiago Jung Bauermann
> >>
> >>In order to safely use the DMA API, virtio needs to know whether DMA
> >>addresses are in fa
67 matches
Mail list logo
