Hi,
On 07/11/2018 10:18 AM, Peter Xu wrote:
> On Mon, Jul 09, 2018 at 01:22:55PM +0800, Lu Baolu wrote:
>> This patch adds the interfaces for per PCI device pasid
>> table management. Currently we allocate one pasid table
>> for all PCI devices under the scope of an IOMMU. It's
>> insecure in some
2018-07-10 18:50 GMT+09:00 Michal Hocko :
> On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
>> Hello, Marek.
>>
>> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
>> > cma_alloc() function doesn't really support gfp flags other than
>> > __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn par
On Wed, Jul 11, 2018 at 03:26:21PM +0800, Lu Baolu wrote:
[...]
> >> +int intel_pasid_alloc_table(struct device *dev)
> >> +{
> >> + struct device_domain_info *info;
> >> + struct pasid_table *pasid_table;
> >> + struct pasid_table_opaque data;
> >> + struct page *pages;
> >> + size_t size,
On Wed 11-07-18 16:35:28, Joonsoo Kim wrote:
> 2018-07-10 18:50 GMT+09:00 Michal Hocko :
> > On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
> >> Hello, Marek.
> >>
> >> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
> >> > cma_alloc() function doesn't really support gfp flags other than
> >> > __GFP_N
On Sunday, July 8, 2018 7:34:10 PM CEST Vivek Gautam wrote:
> 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 devi
On Sunday, July 8, 2018 7:34:11 PM CEST Vivek Gautam wrote:
> From: Sricharan R
>
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context of the master device. So calling runtime apis in those pla
On Sunday, July 8, 2018 7:34:12 PM CEST Vivek Gautam wrote:
> 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
Hi Rafael,
Thanks for review.
On Wed, Jul 11, 2018 at 6:53 PM Rafael J. Wysocki wrote:
>
> On Sunday, July 8, 2018 7:34:11 PM CEST Vivek Gautam wrote:
> > From: Sricharan R
> >
> > The smmu device probe/remove and add/remove master device callbacks
> > gets called when the smmu is not linked to
Hi Rafael,
On 7/11/2018 3:23 PM, Rafael J. Wysocki wrote:
On Sunday, July 8, 2018 7:34:12 PM CEST Vivek Gautam wrote:
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 f
Hi Rafael,
On Wed, Jul 11, 2018 at 3:20 PM, Rafael J. Wysocki wrote:
> On Sunday, July 8, 2018 7:34:10 PM CEST Vivek Gautam wrote:
>> 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
On Wed, Jul 11, 2018 at 12:05 PM, Tomasz Figa wrote:
> Hi Rafael,
>
> Thanks for review.
>
> On Wed, Jul 11, 2018 at 6:53 PM Rafael J. Wysocki wrote:
>>
>> On Sunday, July 8, 2018 7:34:11 PM CEST Vivek Gautam wrote:
>> > From: Sricharan R
>> >
>> > The smmu device probe/remove and add/remove mas
On Wed, Jul 11, 2018 at 12:55 PM, Vivek Gautam
wrote:
> Hi Rafael,
>
>
> On Wed, Jul 11, 2018 at 3:20 PM, Rafael J. Wysocki wrote:
>> On Sunday, July 8, 2018 7:34:10 PM CEST Vivek Gautam wrote:
>>> From: Sricharan R
>>>
>>> The smmu needs to be functional only when the respective
>>> master's us
On 7/11/2018 4:29 PM, Rafael J. Wysocki wrote:
On Wed, Jul 11, 2018 at 12:05 PM, Tomasz Figa wrote:
Hi Rafael,
Thanks for review.
On Wed, Jul 11, 2018 at 6:53 PM Rafael J. Wysocki wrote:
On Sunday, July 8, 2018 7:34:11 PM CEST Vivek Gautam wrote:
From: Sricharan R
The smmu device probe
On Wed, Jul 11, 2018 at 01:46:31PM +0100, Maciej W. Rozycki wrote:
> > Only loongson-3 is DMA coherent and uses swiotlb. So move the dma
> > address translations stubs directly to the loongson-3 code, and remove
> > a few Kconfig indirections.
>
> SiByte should too though, at least for those boa
On Wed, Jul 11, 2018 at 8:11 PM Rafael J. Wysocki wrote:
>
> On Wed, Jul 11, 2018 at 12:55 PM, Vivek Gautam
> wrote:
> > Hi Rafael,
> >
> >
> > On Wed, Jul 11, 2018 at 3:20 PM, Rafael J. Wysocki
> > wrote:
> >> On Sunday, July 8, 2018 7:34:10 PM CEST Vivek Gautam wrote:
> >>> From: Sricharan R
On Fri, 25 May 2018, Christoph Hellwig wrote:
> Only loongson-3 is DMA coherent and uses swiotlb. So move the dma
> address translations stubs directly to the loongson-3 code, and remove
> a few Kconfig indirections.
SiByte should too though, at least for those boards, such as the SWARM
and th
On Wed, 11 Jul 2018, Christoph Hellwig wrote:
> > SiByte should too though, at least for those boards, such as the SWARM
> > and the BigSur, that can have DRAM over 4GiB (and 32-bit PCI devices
> > plugged).
>
> Only in this case refers to loonson boards.
Right!
> > I never got to have the
Hi Tomasz,
On 2018-07-11 14:51, Tomasz Figa wrote:
> On Wed, Jul 11, 2018 at 8:11 PM Rafael J. Wysocki wrote:
>> On Wed, Jul 11, 2018 at 12:55 PM, Vivek Gautam
>> wrote:
>>> On Wed, Jul 11, 2018 at 3:20 PM, Rafael J. Wysocki
>>> wrote:
On Sunday, July 8, 2018 7:34:10 PM CEST Vivek Gautam
On Tue, Jul 10, 2018 at 12:43 PM Robin Murphy wrote:
>
> Whilst the common firmware code invoked by dma_configure() initialises
> devices' DMA masks according to limitations described by the respective
> properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
> the dma_set_mask() AP
ping? Any comments?
On Tue, Jun 19, 2018 at 09:01:37AM +0200, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/nios2/Kconfig | 3 +
> arch/nios2/include/asm/Kbuild| 1 +
>
ping? Any comments?
On Tue, Jun 19, 2018 at 09:03:16AM +0200, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/xtensa/Kconfig | 3 +
> arch/xtensa/include/asm/Kbuild| 1 +
ping? Any comments?
On Tue, Jun 19, 2018 at 09:04:52AM +0200, Christoph Hellwig wrote:
> This should address all the comments raised last time.
>
>
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailm
On 11/07/18 15:40, Rob Herring wrote:
On Tue, Jul 10, 2018 at 12:43 PM Robin Murphy wrote:
Whilst the common firmware code invoked by dma_configure() initialises
devices' DMA masks according to limitations described by the respective
properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the
On 10/07/18 19:04, Christoph Hellwig wrote:
On Tue, Jul 10, 2018 at 06:17:16PM +0100, Robin Murphy wrote:
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8be8106270c2..95e185347e34 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -183,7 +183,7 @@ int dma_direct_supporte
On Wed, Jul 11, 2018 at 10:57:30AM -0700, Max Filippov wrote:
> > config XTENSA
> > def_bool y
> > select ARCH_NO_COHERENT_DMA_MMAP if !MMU
> > + select ARCH_HAS_SYNC_DMA_FOR_CPU
> > + select ARCH_HAS_SYNC_DMA_FOR_DEVICE
>
> This breaks alphabetical order of selects. O
Hi Christoph,
On Tue, Jun 19, 2018 at 12:03 AM, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/xtensa/Kconfig | 3 +
> arch/xtensa/include/asm/Kbuild| 1 +
> arch/xtensa/
On 10/07/18 19:04, Christoph Hellwig wrote:
On Tue, Jul 10, 2018 at 06:17:17PM +0100, Robin Murphy wrote:
When an explicit DMA limit is described by firmware, we need to remember
it regardless of how drivers might subsequently update their devices'
masks. The new bus_dma_mask field does that.
On Wed, Jul 11, 2018 at 11:00 AM, Christoph Hellwig wrote:
> On Wed, Jul 11, 2018 at 10:57:30AM -0700, Max Filippov wrote:
>> > config XTENSA
>> > def_bool y
>> > select ARCH_NO_COHERENT_DMA_MMAP if !MMU
>> > + select ARCH_HAS_SYNC_DMA_FOR_CPU
>> > + select ARCH_HAS_SY
On Tue, Jul 10, 2018 at 04:22:22PM -0700, Kees Cook wrote:
> This removes needless use of '%p', and refactors the printk calls to
> use pr_*() helpers instead.
>
> Signed-off-by: Kees Cook
Reviewed-by: Konrad Rzeszutek Wilk
Christoph, volunteered to pick this patch up in his tree. Thank you!
>
On Wed, Jul 11, 2018 at 3:40 PM, Marek Szyprowski
wrote:
> Hi Tomasz,
>
> On 2018-07-11 14:51, Tomasz Figa wrote:
>> On Wed, Jul 11, 2018 at 8:11 PM Rafael J. Wysocki wrote:
>>> On Wed, Jul 11, 2018 at 12:55 PM, Vivek Gautam
>>> wrote:
On Wed, Jul 11, 2018 at 3:20 PM, Rafael J. Wysocki
>>
This allows the default behavior to be controlled by a kernel config
option instead of changing the commandline for the kernel to include
"iommu.passthrough=on" on machines where this is desired.
Signed-off-by: Olof Johansson
---
drivers/iommu/Kconfig | 10 ++
drivers/iommu/iommu.c | 4
While we could print it at setup time, this is an easier way to match
each device to their default IOMMU allocation type.
Signed-off-by: Olof Johansson
---
drivers/iommu/iommu.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/
Hi, Olof,
Tired of changing command line. I like this patch.
Thanks.
Shunyong.
On Wed, 2018-07-11 at 13:59 -0700, Olof Johansson wrote:
> This allows the default behavior to be controlled by a kernel config
> option instead of changing the commandline for the kernel to include
> "iommu.passthro
2018-07-11 17:54 GMT+09:00 Michal Hocko :
> On Wed 11-07-18 16:35:28, Joonsoo Kim wrote:
>> 2018-07-10 18:50 GMT+09:00 Michal Hocko :
>> > On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
>> >> Hello, Marek.
>> >>
>> >> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
>> >> > cma_alloc() function doesn't
Avoid below warning when new capabilities added:
drivers/iommu/amd_iommu.c: In function 'amd_iommu_capable':
drivers/iommu/amd_iommu.c:3053:2: warning: enumeration value
'IOMMU_CAP_NON_STRICT' not handled in switch [-Wswitch]
switch (cap) {
Signed-off-by: Zhen Lei
---
drivers/iommu/amd_io
To support the non-strict mode, now we only tlbi and sync for the strict
mode. But for the non-leaf case, always follow strict mode.
Use the lowest bit of the iova parameter to pass the strict mode:
0, IOMMU_STRICT;
1, IOMMU_NON_STRICT;
Treat 0 as IOMMU_STRICT, so that the unmap operation can comp
1. Add IOMMU_CAP_NON_STRICT capability.
2. Dynamic choose strict or non-strict mode base on the iommu domain type.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smm
v2 -> v3:
Add a bootup option "iommu_strict_mode" to make the manager can choose which
mode to be used. The first 5 patches have not changed.
+ iommu_strict_mode= [arm-smmu-v3]
+ 0 - strict mode (default)
+ 1 - non-strict mode
v1 -> v2:
Use the lowest bit of
.flush_iotlb_all can not just wait for previous tlbi operations to be
completed, but should also invalid all TLBs of the related domain.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3
1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
capable call domain->ops->flush_iotlb_all to flush TLB.
2. Add a new iommu capability: IOMMU_CAP_NON_STRICT, which used to indicate
that the iommu domain support non-strict mode.
3. During the iommu domain initializatio
Because the non-strict mode introduces a vulnerability window, so add a
bootup option to make the manager can choose which mode to be used. The
default mode is IOMMU_STRICT.
Signed-off-by: Zhen Lei
---
Documentation/admin-guide/kernel-parameters.txt | 12 ++
drivers/iommu/arm-smmu-v3.c
41 matches
Mail list logo
