Hi All,
Could you please test Christoph's kernel on your PASEMI and NXP boards?
Download:
'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'
Thanks,
Christian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lis
Hi,
Is this solution trying to support general user space processes who
are directly working on devices?
Yes, it is.
Okay. But I got another question. As I write a Crypto driver, could I
call 'mdev_register_device'?
Or in other words, is 'mdev_register_device' acceptable for drivers of
C
On Mon, Dec 3, 2018 at 11:52 AM Mike Rapoport wrote:
>
> On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> > Hi Mike,
> >
> > On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> > >
> > > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > > Previouly drive
On Mon, Dec 3, 2018 at 7:56 PM Rob Clark wrote:
>
> On Mon, Dec 3, 2018 at 7:45 AM Robin Murphy wrote:
> >
> > Hi Rob,
> >
> > On 01/12/2018 16:53, Rob Clark wrote:
> > > This solves a problem we see with drm/msm, caused by getting
> > > iommu_dma_ops while we attach our own domain and manage it
Add bindings doc for Qcom's smmu-v2 implementation.
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
Tested-by: Srinivas Kandagatla
Reviewed-by: Rob Herring
Reviewed-by: Robin Murphy
---
Changes since v18:
None.
.../devicetree/bindings/iommu/arm,smmu.txt | 39 +
Hi,
On 12/4/18 11:46 AM, Xu Zaibo wrote:
Hi,
Is this solution trying to support general user space processes who are
directly working on devices?
Yes, it is.
Thanks,
Zaibo
Best regards,
Lu Baolu
.
On 2018/11/5 15:34, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-g
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Signed-off-by: Sricharan R
Signed-of
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements.
On msm8996, multiple cores, viz. mdss, video, etc. use this
smmu. On sdm845, this smmu is used with gpu.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Reviewed-by: Tomasz F
From: Sricharan R
Enable pm-runtime on devices that implement a pm domain. Then,
add pm runtime hooks to several iommu_ops to power cycle the
smmu device for explicit TLB invalidation requests, and
register space accesses, etc.
We need these hooks when the smmu, linked to its master through
devic
Changes since v18:
- Addressing Stephen's comment [5]:
Replaced the entire clock bulk data filling and handling with
devm_clk_bulk_get_all().
Changes since v17:
- Addressing Will's comment to embed Thor's change [2] for pulling
clocks information from device tree. This is done by sq
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
r
Hi,
On 12/4/18 1:23 AM, Liu, Yi L wrote:
Hi Joerg,
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Monday, December 3, 2018 5:49 AM
To: Lu Baolu
Subject: Re: [PATCH v5 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
support
On Wed, Nov 28, 2018 at 11:54:41AM +0800, Lu Baolu wrote:
Hi,
On 12/4/18 1:23 AM, Liu, Yi L wrote:
Hi Joerg,
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Monday, December 3, 2018 5:44 AM
To: Lu Baolu
Subject: Re: [PATCH v5 02/12] iommu/vt-d: Manage scalalble mode PASID tables
Hi Baolu,
On Wed, Nov 28, 2018 at 11:54:39AM +0800, Lu Baolu wrote:
Hi,
Is this solution trying to support general user space processes who are
directly working on devices?
Thanks,
Zaibo
.
On 2018/11/5 15:34, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framew
Enabling CONFIG_ARM_SMMU_TEGRA that is used
by Tegra194 SOC.
Signed-off-by: Krishna Reddy
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5c2b1f6..e5ea13b 100644
--- a/arch/arm64/configs/defcon
Add support to program multiple ARM SMMU's identically as one SMMU device.
Tegra194 uses Two ARM SMMU's as one SMMU device and both ARM SMMU's need
to be programmed identically.
Signed-off-by: Krishna Reddy
---
drivers/iommu/lib-arm-smmu.c | 191 ---
1 fil
Add SMMU nodes and dma-ranges to Tegra194 device tree.
Tegra194 has three ARM SMMU Instances. Two of them are used
together to access IOVA interleaved. The third one is used
as regular ARM SMMU.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 148 +
Create library routines to share ARM SMMU programming
and common IOMMU API implementation for ARM SMMU v1 and v2
based architecture Implementations.
Signed-off-by: Krishna Reddy
---
drivers/iommu/Makefile |1 +
drivers/iommu/lib-arm-smmu.c | 1671 +++
Update ARM SMMU driver to use the ARM SMMU library routines.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 1709 +-
1 file changed, 11 insertions(+), 1698 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
inde
Tegra194 SMMU driver supports Dual ARM SMMU configuration
necessary for Tegra194 SOC.
The IOVA accesses from HW devices are interleaved across two
ARM SMMU devices transparently.
Signed-off-by: Krishna Reddy
---
drivers/iommu/Kconfig | 11 ++
drivers/iommu/Makefile| 1 +
drive
NVIDIA's Xavier (Tegra194) SOC has two ARM SMMU(MMU-500) instances, which
are used as one SMMU device in HW. The IOVA accesses from HW devices are
interleaved across these two SMMU instances and need to be programmed identical.
The existing ARM SMMU driver can't be used in its current form for pro
On Thu, Nov 29, 2018 at 06:51:50PM +0300, Mika Westerberg wrote:
> A malicious PCI device may use DMA to attack the system. An external
> Thunderbolt port is a convenient point to attach such a device. The OS
> may use IOMMU to defend against DMA attacks.
>
> Recent BIOSes with Thunderbolt ports m
Quoting Vivek Gautam (2018-12-02 22:43:38)
> On Fri, Nov 30, 2018 at 11:45 PM Will Deacon wrote:
> >
> > On Thu, Nov 29, 2018 at 08:25:20PM +0530, Vivek Gautam wrote:
> > > clk_bulk_get_all() seems like going only the OF way.
> > > Is there another way here to have something common between ACPI
>
On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> global
On 03/12/2018 17:28, Robin Murphy wrote:
Certain drivers such as large multi-queue network adapters can use pools
of mapped DMA buffers larger than the default dma_debug_entry pool of
65536 entries, with the result that merely probing such a device can
cause DMA debug to disable itself during boo
On Mon, Dec 03, 2018 at 11:56:11AM +, John Garry wrote:
> On 01/12/2018 16:36, Christoph Hellwig wrote:
>> On Fri, Nov 30, 2018 at 07:39:50PM +, Robin Murphy wrote:
>>> I was assuming the point was to also add something like
>>>
>>> default 131072 if HNS_ENET
>>>
>>> so that DMA debug d
On Mon, Dec 03, 2018 at 05:28:05PM +, Robin Murphy wrote:
> The HNS_ENET discussion got me thinking, why not just make DMA debug
> cleverer so that (in terms of basic functionality at least) we don't
> need to worry about driver- or arch-specific configuration at all?
>
> Patches #2 and #3 are
Use pr_fmt() to generate the "DMA-API: " prefix consistently. This
results in it being added to a couple of pr_*() messages which were
missing it before, and for the err_printk() calls moves it to the actual
start of the message instead of somewhere in the middle.
Signed-off-by: Robin Murphy
---
The HNS_ENET discussion got me thinking, why not just make DMA debug
cleverer so that (in terms of basic functionality at least) we don't
need to worry about driver- or arch-specific configuration at all?
Patches #2 and #3 are the real meat here - #1 is just some preparatory
cleanup motivated by m
Make prealloc_memory() a little more general and robust so that it
serves for runtime reallocations too. The first thing we can do with
that is clean up dma_debug_resize_entries() quite a bit.
Signed-off-by: Robin Murphy
---
kernel/dma/debug.c | 95 +++---
Certain drivers such as large multi-queue network adapters can use pools
of mapped DMA buffers larger than the default dma_debug_entry pool of
65536 entries, with the result that merely probing such a device can
cause DMA debug to disable itself during boot unless explicitly given an
appropriate "d
Now that we can dynamically allocate DMA debug entries to cope with
drivers maintaining excessively large numbers of live mappings, a driver
which *does* actually have a bug leaking mappings (and is not unloaded)
will no longer trigger the "DMA-API: debugging out of memory - disabling"
message unti
Does anyone but Linus and Russell have comments on this series?
I'd like to pull it in fairly quickly as I have a fair amount of
work on top of it that I'd like to get into 4.21 as well.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lis
Hi Joerg,
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Monday, December 3, 2018 5:44 AM
> To: Lu Baolu
> Subject: Re: [PATCH v5 02/12] iommu/vt-d: Manage scalalble mode PASID tables
>
> Hi Baolu,
>
> On Wed, Nov 28, 2018 at 11:54:39AM +0800, Lu Baolu wrote:
> > @@ -2482,12 +2482,13 @@
Hi Joerg,
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Monday, December 3, 2018 5:49 AM
> To: Lu Baolu
> Subject: Re: [PATCH v5 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
> support
>
> On Wed, Nov 28, 2018 at 11:54:41AM +0800, Lu Baolu wrote:
> > -
> > - desc_page = alloc_
On 11/21/2018 2:15 PM, Christoph Hellwig wrote:
> On Wed, Nov 21, 2018 at 02:22:08AM +0530, Kirti Wankhede wrote:
>> It is about how mdev framework can be used by existing drivers. These
>> symbols doesn't use any other exported symbols.
>
> That is an unfortunate accident of history, but doesn
On Mon, Dec 3, 2018 at 7:45 AM Robin Murphy wrote:
>
> Hi Rob,
>
> On 01/12/2018 16:53, Rob Clark wrote:
> > This solves a problem we see with drm/msm, caused by getting
> > iommu_dma_ops while we attach our own domain and manage it directly at
> > the iommu API level:
> >
> >[0038
On Mon, Dec 3, 2018 at 7:45 AM Robin Murphy wrote:
>
> Hi Rob,
>
> On 01/12/2018 16:53, Rob Clark wrote:
> > This solves a problem we see with drm/msm, caused by getting
> > iommu_dma_ops while we attach our own domain and manage it directly at
> > the iommu API level:
> >
> >[0038
On Wed, Nov 28, 2018 at 11:54:41AM +0800, Lu Baolu wrote:
> -
> - desc_page = alloc_pages_node(iommu->node, GFP_ATOMIC | __GFP_ZERO, 0);
> + /*
> + * Need two pages to accommodate 256 descriptors of 256 bits each
> + * if the remapping hardware supports scalable mode translation.
Hi Baolu,
On Wed, Nov 28, 2018 at 11:54:39AM +0800, Lu Baolu wrote:
> @@ -2482,12 +2482,13 @@ static struct dmar_domain
> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> if (dev)
> dev->archdata.iommu = info;
>
> - if (dev && dev_is_pci(dev) && info->pasid_support
On Sat, Dec 01, 2018 at 02:19:08PM -0500, Paul Gortmaker wrote:
> Paul Gortmaker (9):
> iommu: audit and remove any unnecessary uses of module.h
> iommu/rockchip: Make it explicitly non-modular
> iommu/msm: Make it explicitly non-modular
> iommu/mediatek: Make it explicitly non-modular
>
Hi Michael,
On 11/27/18 6:16 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2018 at 06:09:25PM +0100, Auger Eric wrote:
>> Hi Michael,
>>
>> On 11/27/18 5:53 PM, Michael S. Tsirkin wrote:
>>> On Thu, Nov 22, 2018 at 07:37:54PM +, Jean-Philippe Brucker wrote:
Implement the virtio-iommu dr
On Fri, Nov 30, 2018 at 09:35:21AM -0500, Yangtao Li wrote:
> seq_file.h does not need to be included,so remove it.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/iommu/irq_remapping.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
___
iommu m
On Wed, Nov 28, 2018 at 09:23:35AM +, Yoshihiro Shimoda wrote:
> Yoshihiro Shimoda (2):
> iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist() to check SoC
> revisions
> iommu/ipmmu-vmsa: add an array of slave devices whitelist
Applied, thanks.
_
Hi Rob,
On 01/12/2018 16:53, Rob Clark wrote:
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#
On 01/12/2018 16:36, Christoph Hellwig wrote:
On Fri, Nov 30, 2018 at 07:39:50PM +, Robin Murphy wrote:
I was assuming the point was to also add something like
default 131072 if HNS_ENET
so that DMA debug doesn't require too much thought from the user. If they
still have to notice
Thanks for the info.
Yes. we need to do this as our architecture manages everything from one of
super privileged guest .
Rest of the guest don't have access to these devices .
Let me check with hardware vendor to see if we can segregate SMBus device
into separate iommu group.
-Gokul
On Fri, Nov
Hi Tomasz,
On 2018-12-03 01:10, Tomasz Figa wrote:
> On Sat, Dec 1, 2018 at 8:54 AM Rob Clark wrote:
>> This solves a problem we see with drm/msm, caused by getting
>> iommu_dma_ops while we attach our own domain and manage it directly at
>> the iommu API level:
>>
>> [0038] user ad
From: He Zhe
setup_io_tlb_npages does not check input argument before passing it
to isdigit. The argument would be a NULL pointer if "swiotlb", without
its value, is set in command line and thus causes the following panic.
PANIC: early exception 0xe3 IP 10:bb9b8e9f error 0 cr2 0x0
[0
On 2018/12/2 20:30, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 30, 2018 at 07:06:10PM +0800, He Zhe wrote:
>>
>> On 2018/10/23 19:14, He Zhe wrote:
>>> On 2018/10/23 03:29, Konrad Rzeszutek Wilk wrote:
On Sat, Sep 22, 2018 at 08:56:58PM +0800, He Zhe wrote:
> May I have your input?
Hi Matthias,
Thanks very much for your review.
On Mon, 2018-12-03 at 00:56 +0100, Matthias Brugger wrote:
>
> On 17/11/2018 03:35, Yong Wu wrote:
> > The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> > the ARM Short-descriptor like mt8173, and most of the HW registers
>
On Mon, 2018-12-03 at 00:04 +0100, Matthias Brugger wrote:
>
> On 17/11/2018 03:35, Yong Wu wrote:
> > The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> > It's no need to parse it again in SMI driver. Only clean some codes.
> > This patch is fit for all the current mt2701, mt27
52 matches
Mail list logo
