On 11/26/2018 11:33 AM, Vivek Gautam wrote:
On 11/24/2018 12:06 AM, Will Deacon wrote:
On Thu, Nov 22, 2018 at 05:32:24PM +0530, Vivek Gautam wrote:
Hi Will,
On Wed, Nov 21, 2018 at 11:09 PM Will Deacon
wrote:
On Fri, Nov 16, 2018 at 04:54:27PM +0530, Vivek Gautam wrote:
From:
On 11/24/2018 12:04 AM, Will Deacon wrote:
On Fri, Nov 23, 2018 at 03:06:29PM +0530, Vivek Gautam wrote:
On Fri, Nov 23, 2018 at 2:52 PM Tomasz Figa wrote:
On Fri, Nov 23, 2018 at 6:13 PM Vivek Gautam
wrote:
On Wed, Nov 21, 2018 at 11:09 PM Will Deacon wrote:
On Fri, Nov 16, 2018 at
On Fri, Nov 23, 2018 at 01:23:41PM +0100, Vlastimil Babka wrote:
> Is this also true for caches created by kmem_cache_create(), that
> debugging options can result in not respecting the alignment passed to
> kmem_cache_create()? That would be rather bad, IMHO.
That's what I understood in the
Currently Linux automatically enables ATS (Address Translation Service)
for any device that supports it (and IOMMU is turned on). ATS is used to
accelerate DMA access as the device can cache translations locally so
there is no need to do full translation on IOMMU side. However, as
pointed out in
From: Lu Baolu
Intel VT-d spec added a new DMA_CTRL_PLATFORM_OPT_IN_FLAG flag
in DMAR ACPI table for BIOS to report compliance about platform
initiated DMA restricted to RMRR ranges when transferring control
to the OS. The OS treats this as a hint that the IOMMU should be
enabled to prevent DMA
Recent systems shipping with Windows 10 version 1803 or newer may be
utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is
different from the previous security level based scheme because the
connected device cannot access system memory outside of the regions
allocated for it by the
Recent systems with Thunderbolt ports may support IOMMU natively. In
practice this means that Thunderbolt connected devices are placed behind
an IOMMU during the whole time it is connected (including during boot)
making Thunderbolt security levels redundant. This is called Kernel DMA
protection
Recent systems with Thunderbolt ports may support IOMMU natively. This
means that the platform utilizes IOMMU to prevent DMA attacks over
externally exposed PCIe root ports (typically Thunderbolt ports)
The system BIOS marks these PCIe root ports as being externally facing
ports by implementing
OK, so I enabled CONFIG_DMA_API_DEBUG: and now I get:
[ 178.789451] [ cut here ]
[ 178.789558] DMA-API: exceeded 7 overlapping mappings of cacheline
0x1a161a80
[ 178.789578] WARNING: CPU: 7 PID: 1223 at kernel/dma/debug.c:523
add_dma_entry+0x1f6/0x200
[
Hi Mika,
On Mon, Nov 26, 2018 at 02:15:23PM +0300, Mika Westerberg wrote:
> Recent systems with Thunderbolt ports may support IOMMU natively.
This sentence doesn't make sense to me. There's no logical connection
between having an IOMMU and having a Thunderbolt port.
> This means that the
On Mon, 2018-11-26 at 17:31 -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/iommu/Kconfig:config MTK_IOMMU_V1
> drivers/iommu/Kconfig: bool "MTK IOMMU Version 1 (M4U gen1) Support"
>
> ...meaning that it currently is not being built as a
Hi Krishna,
On Wed, Oct 31, 2018 at 04:43:45PM -0700, Krishna Reddy wrote:
> NVIDIA's Xavier (Tegra194) SOC has three ARM SMMU(MMU-500) instances.
> Two of the SMMU instances are used to interleave IOVA accesses across them.
> The IOVA accesses from HW devices are interleaved across these two
Hi Olof,
Thanks for the comments!
>>Based on what I can see, it seems that you're trying to describe two
pieces of hardware with only one device in the DT. That seems like an
odd choice.
T194 SOC HW is designed to use Two ARM SMMU's together like one SMMU.
The IOVA accesses from the HW
Hi Jean,
> -Original Message-
> From: Auger Eric
> Sent: Friday, November 23, 2018 1:59 PM
> To: Jean-Philippe Brucker ;
> iommu@lists.linux-foundation.org; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; virtualizat...@lists.linux-foundation.org; virtio-
>
Anshuman Khandual writes:
> 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 macro NUMA_NO_NODE. This helps
On Wed, Aug 29, 2018 at 11:29:21PM +0200, Niklas Söderlund wrote:
> The function dma_set_max_seg_size() can return either 0 on success or
> -EIO on error. Change its return type from unsigned int to int to
> capture this.
>
> Signed-off-by: Niklas Söderlund
Thanks, applied to the dma-mapping
On Mon, Nov 26, 2018 at 10:41:02PM +0100, Boris Brezillon wrote:
> On Mon, 26 Nov 2018 12:36:03 -0800
> Eric Anholt wrote:
>
> > Michael Zoran writes:
> >
> > > On Fri, 2018-11-23 at 11:27 +0900, Tomasz Figa wrote:
> > >>
> > >> The point here is not about setting and resetting the
Any comments? I'd like to at least get the ball moving on the easy
bits.
On Wed, Nov 14, 2018 at 09:22:40AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series switches the powerpc port to use the generic swiotlb and
> noncoherent dma ops, and to use more generic code for the coherent
>
On Thu, Nov 15, 2018 at 12:58:04PM -0800, Robin Murphy wrote:
> On 2018-11-15 11:50 am, Will Deacon wrote:
>> On Fri, Nov 09, 2018 at 08:52:38AM +0100, Christoph Hellwig wrote:
>>> Can I get a quick review from the arm64 folks? I think it should
>>> be fine there as it basically is a code move,
On 11/26/2018 06:18 PM, David Hildenbrand wrote:
> On 26.11.18 13:26, 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
On 26/11/2018 06:44, Souptick Joarder wrote:
On Sat, Nov 24, 2018 at 3:04 AM Matthew Wilcox wrote:
On Fri, Nov 23, 2018 at 05:23:06PM +, Robin Murphy wrote:
On 15/11/2018 15:49, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
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 macro NUMA_NO_NODE. This helps remove NUMA related assumptions
On 26.11.18 13:26, 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 macro
After removing an entry from a queue (e.g. reading an event in
arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer
pointer to free the queue slot back to the SMMU. A memory barrier is
required here so that all reads targetting the queue entry have
completed before the consumer
On Mon, Nov 26, 2018 at 07:31:48PM +, Will Deacon wrote:
> Hi Rob,
>
> On Tue, Nov 13, 2018 at 08:12:35AM -0500, Rob Clark wrote:
> > On Tue, Nov 13, 2018 at 1:32 AM Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 01:01:55PM -0500, Rob Clark wrote:
> > > > On Mon, Oct 29, 2018 at 3:09 PM
On Mon, Nov 26, 2018 at 04:56:42PM +0530, Vivek Gautam wrote:
> On 11/26/2018 11:33 AM, Vivek Gautam wrote:
> >On 11/24/2018 12:06 AM, Will Deacon wrote:
> >>On Thu, Nov 22, 2018 at 05:32:24PM +0530, Vivek Gautam wrote:
> >>>On Wed, Nov 21, 2018 at 11:09 PM Will Deacon
> >>>wrote:
> On Fri,
Hi Rob,
On Tue, Nov 13, 2018 at 08:12:35AM -0500, Rob Clark wrote:
> On Tue, Nov 13, 2018 at 1:32 AM Will Deacon wrote:
> > On Fri, Nov 09, 2018 at 01:01:55PM -0500, Rob Clark wrote:
> > > On Mon, Oct 29, 2018 at 3:09 PM Will Deacon wrote:
> > > > On Thu, Sep 27, 2018 at 06:46:07PM -0400, Rob
Hi Robin,
On Fri, Nov 23, 2018 at 07:34:15PM +, Robin Murphy wrote:
> On 2018-11-23 6:27 pm, Will Deacon wrote:
> >On Tue, Nov 20, 2018 at 10:25:16AM +0100, Christoph Hellwig wrote:
> >>On Mon, Nov 19, 2018 at 03:22:13PM -0800, John Stultz wrote:
> + sg->dma_address =
Hi Vivek,
On 11/26/18 4:55 AM, Vivek Gautam wrote:
On 11/24/2018 12:04 AM, Will Deacon wrote:
On Fri, Nov 23, 2018 at 03:06:29PM +0530, Vivek Gautam wrote:
On Fri, Nov 23, 2018 at 2:52 PM Tomasz Figa wrote:
On Fri, Nov 23, 2018 at 6:13 PM Vivek Gautam
wrote:
On Wed, Nov 21, 2018 at 11:09
Hi Thor,
On 11/26/2018 8:11 PM, Thor Thayer wrote:
Hi Vivek,
On 11/26/18 4:55 AM, Vivek Gautam wrote:
On 11/24/2018 12:04 AM, Will Deacon wrote:
On Fri, Nov 23, 2018 at 03:06:29PM +0530, Vivek Gautam wrote:
On Fri, Nov 23, 2018 at 2:52 PM Tomasz Figa
wrote:
On Fri, Nov 23, 2018 at 6:13
On 2018-11-02 11:22:54 +0100, Niklas Söderlund wrote:
> Hi,
>
> A gentle ping on this patch.
A slightly harder ping :-)
>
> On 2018-08-29 23:29:21 +0200, Niklas Söderlund wrote:
> > The function dma_set_max_seg_size() can return either 0 on success or
> > -EIO on error. Change its return type
On 11/26/18 10:56 AM, Jeff Kirsher wrote:
> 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
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config MTK_IOMMU_V1
drivers/iommu/Kconfig: bool "MTK IOMMU Version 1 (M4U gen1) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config MSM_IOMMU
drivers/iommu/Kconfig: bool "MSM IOMMU Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ROCKCHIP_IOMMU
drivers/iommu/Kconfig: bool "Rockchip IOMMU Support"
...meaning that it currently is not being built as a module by anyone.
The bind/unbind/remove was already explicitly disabled in
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config IPMMU_VMSA
drivers/iommu/Kconfig:bool "Renesas VMSA-compatible IPMMU"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config MTK_IOMMU_V1
drivers/iommu/Kconfig: bool "MTK IOMMU Version 1 (M4U gen1) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config TEGRA_IOMMU_GART
drivers/iommu/Kconfig: bool "Tegra GART IOMMU Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned,
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ARM_SMMU_V3
drivers/iommu/Kconfig: bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ARM_SMMU
drivers/iommu/Kconfig: bool "ARM Ltd. System MMU (SMMU) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends. That changed
when we forked out support for the latter into the export.h file.
This means we should be able to reduce
The work here represents a scan over the iommu dir, looking for files/drivers
that have nothing to do with a modular use case, but are using modular
infrastructure regardless.
We are trying to make driver code consistent with the Makefiles/Kconfigs that
control them. This means not using modular
On Mon, Nov 26, 2018 at 2:31 PM Will Deacon wrote:
>
> Hi Rob,
>
> On Tue, Nov 13, 2018 at 08:12:35AM -0500, Rob Clark wrote:
> > On Tue, Nov 13, 2018 at 1:32 AM Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 01:01:55PM -0500, Rob Clark wrote:
> > > > On Mon, Oct 29, 2018 at 3:09 PM Will
On Mon, 26 Nov 2018 12:36:03 -0800
Eric Anholt wrote:
> Michael Zoran writes:
>
> > On Fri, 2018-11-23 at 11:27 +0900, Tomasz Figa wrote:
> >>
> >> The point here is not about setting and resetting the plane->fb
> >> pointer. It's about what happens inside
> >>
Am Montag, 26. November 2018, 23:31:31 CET schrieb Paul Gortmaker:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/iommu/Kconfig:config ROCKCHIP_IOMMU
> drivers/iommu/Kconfig: bool "Rockchip IOMMU Support"
>
> ...meaning that it currently is not being built as a
45 matches
Mail list logo
