The pull request you sent on Fri, 29 Jan 2021 17:41:29 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.11-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8ef24c2011b77bd6344d16630d3cd95d63de63f8
Thank you!
--
On 2021/1/29 23:27, Robin Murphy wrote:
> On 2021-01-27 11:32, Zhen Lei wrote:
>> commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
>> defined register space") only reserves the basic SMMU register space. So
>> the ECMDQ register space is not covered, it should be mapped
v3 --> v4:
1. Delete the unnecessary encapsulation function
smmu_pmu_get_and_ioremap_resource().
2. Discard adding MODULE_SOFTDEP.
v2 --> v3:
Patch 3 is updated because https://lkml.org/lkml/2021/1/22/532 has been queued
in advance.
v1 --> v2:
According to Robin Murphy's suggestion:
According to the SMMUv3 specification:
Each PMCG counter group is represented by one 4KB page (Page 0) with one
optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
DEFINED base addresses.
This means that the PMCG register spaces may be within the 64KB pages of
the SMMUv3
commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
defined register space") only reserves the basic SMMU register space. So
the ECMDQ register space is not covered, it should be mapped again. Due
to the size of this ECMDQ resource is not fixed, depending on
Hi, Robin:
Can you review this patch again?
On 2021/1/30 15:14, Zhen Lei wrote:
> According to the SMMUv3 specification:
> Each PMCG counter group is represented by one 4KB page (Page 0) with one
> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
> DEFINED base
On 2021/1/29 23:06, Robin Murphy wrote:
> On 2021-01-27 11:32, Zhen Lei wrote:
>> According to the SMMUv3 specification:
>> Each PMCG counter group is represented by one 4KB page (Page 0) with one
>> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
>> DEFINED base
On 2021/1/30 1:03, Robin Murphy wrote:
> On 2021-01-29 15:34, John Garry wrote:
>> On 29/01/2021 15:12, Robin Murphy wrote:
>>> On 2021-01-27 11:32, Zhen Lei wrote:
The MODULE_SOFTDEP() gives user space a hint of the loading sequence. And
when command "modprobe arm_smmuv3_pmu" is
On 2021-01-29 14:35, Will Deacon wrote:
On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote:
Add a new page protection flag IOMMU_LLC which can be used
by non-coherent masters to set cacheable memory attributes
for an outer level of cache called as last-level cache or
system
On Fri, Jan 29, 2021 at 09:52:42AM +0800, Yong Wu wrote:
> On Thu, 2021-01-28 at 21:14 +, Will Deacon wrote:
> > On Thu, Jan 28, 2021 at 09:10:20PM +, Will Deacon wrote:
> > > On Wed, Jan 27, 2021 at 05:39:16PM +0800, Yong Wu wrote:
> > > > On Tue, 2021-01-26 at 22:23 +, Will Deacon
On Thu, Jan 28, 2021 at 10:02:58PM +0900, Yoshihiro Shimoda wrote:
> Yoshihiro Shimoda (2):
> iommu/ipmmu-vmsa: refactor ipmmu_of_xlate()
> iommu/ipmmu-vmsa: Allow SDHI devices
>
> drivers/iommu/ipmmu-vmsa.c | 53
> +++---
> 1 file changed, 22
On 2021-01-20 10:48, Sai Prakash Ranjan wrote:
On 2021-01-11 19:45, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required for the non-coherent masters
On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote:
> Add a new page protection flag IOMMU_LLC which can be used
> by non-coherent masters to set cacheable memory attributes
> for an outer level of cache called as last-level cache or
> system cache. Initial user of this page
This reverts commit 4e89dce725213d3d0b0475211b500eda4ef4bf2f.
We find that this patch has a great impact on performance. According to
our test: the iops decreases from 1655.6K to 893.5K, about half.
Hardware: 1 SAS expander with 12 SAS SSD
Command: Only the main parameters are listed.
On Tue, Jan 26, 2021 at 04:07:28PM +0800, Lu Baolu wrote:
> Lu Baolu (2):
> iommu/vt-d: Clear PRQ overflow only when PRQ is empty
> iommu/vt-d: Use INVALID response code instead of FAILURE
>
> drivers/iommu/intel/svm.c | 18 --
> 1 file changed, 12 insertions(+), 6
Export arm_smmu_get_cd_ptr and arm_smmu_get_step_for_sid to let debug
interface to get related cd and ste.
Signed-off-by: Zhou Wang
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 ---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 ++
2 files changed, 6 insertions(+), 3 deletions(-)
This patch adds debug interfaces for SMMUv3 driver in sysfs. It adds debug
related files under /sys/kernel/debug/iommu/smmuv3.
User should firstly set device and pasid to pci_dev and pasid by:
(currently only support PCI device)
echo ::. > /sys/kernel/debug/iommu/smmuv3/pci_dev
echo >
Export page table walk needed functions and macros, then page table dump
in later debug interface could be used directly.
Signed-off-by: Zhou Wang
---
drivers/iommu/io-pgtable-arm.c | 47 +-
drivers/iommu/io-pgtable-arm.h | 43
This RFC series is the followed patch of this discussion:
https://www.spinics.net/lists/arm-kernel/msg866187.html.
Currently there is no debug interface about SMMUv3 driver, which makes it
not convenient when we want to dump some information, like the value of
CD/STE, S1/S2 page table, SMMU
Currently, we are thinking about the solution to the problem. However, because
the end time of v5.11 is approaching, this patch is sent first.
On 2021/1/29 17:21, Zhen Lei wrote:
> This reverts commit 4e89dce725213d3d0b0475211b500eda4ef4bf2f.
>
> We find that this patch has a great impact on
On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote:
>
> On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
> > On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote:
> > >
> > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> > > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote:
> > > > >
> > > >
On 2021/1/28 22:52, Chuck Lever wrote:
On Jan 28, 2021, at 8:59 AM, Robin Murphy wrote:
On 2021-01-27 20:00, Chuck Lever wrote:
Hi-
This collection of patches seems to get the best throughtput results
so far. The NFS WRITE result is fully restored, and the NFS READ
result is very close to
> From: Song Bao Hua (Barry Song)
> Sent: Tuesday, January 26, 2021 9:27 AM
>
> > -Original Message-
> > From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> > Sent: Tuesday, January 26, 2021 2:13 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: Wangzhou (B) ; Greg Kroah-Hartman
> > ; Arnd
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Friday, January 29, 2021 11:09 PM
> To: Song Bao Hua (Barry Song) ; Jason Gunthorpe
>
> Cc: chensihang (A) ; Arnd Bergmann
> ; Greg Kroah-Hartman ;
> linux-ker...@vger.kernel.org;
On 2021-01-29 09:48, Leizhen (ThunderTown) wrote:
Currently, we are thinking about the solution to the problem. However, because
the end time of v5.11 is approaching, this patch is sent first.
However, that commit was made for a reason - how do we justify that one
thing being slow is more
Hi Yong,
On Mon, Jan 11, 2021 at 07:18:41PM +0800, Yong Wu wrote:
> This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
>
Hi Robin,
在 2021/1/29 20:03, Robin Murphy 写道:
On 2021-01-29 09:48, Leizhen (ThunderTown) wrote:
Currently, we are thinking about the solution to the problem.
However, because the end time of v5.11 is approaching, this patch is
sent first.
However, that commit was made for a reason - how
On 2021-01-27 11:32, Zhen Lei wrote:
According to the SMMUv3 specification:
Each PMCG counter group is represented by one 4KB page (Page 0) with one
optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
DEFINED base addresses.
This means that the PMCG register spaces may be
On 2021-01-27 11:32, Zhen Lei wrote:
commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
defined register space") only reserves the basic SMMU register space. So
the ECMDQ register space is not covered, it should be mapped again. Due
to the size of this ECMDQ resource is not
on x86_64:
../drivers/iommu/intel/dmar.c: In function 'qi_submit_sync':
../drivers/iommu/intel/dmar.c:1311:3: error: implicit declaration of function
'trace_qi_submit'; did you mean 'ftrace_nmi_exit'?
[-Werror=implicit-function-declaration]
trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
On 2021-01-29 15:34, John Garry wrote:
On 29/01/2021 15:12, Robin Murphy wrote:
On 2021-01-27 11:32, Zhen Lei wrote:
The MODULE_SOFTDEP() gives user space a hint of the loading sequence.
And
when command "modprobe arm_smmuv3_pmu" is executed, the
arm_smmu_v3.ko is
automatically loaded in
On 2021/1/29 4:31, Will Deacon wrote:
> On Wed, Jan 27, 2021 at 07:32:55PM +0800, Zhen Lei wrote:
>> v2 --> v3:
>> Patch 3 is updated because https://lkml.org/lkml/2021/1/22/532 has been
>> queued in advance.
>>
>> v1 --> v2:
>> According to Robin Murphy's suggestion:
On 2021-01-27 11:32, Zhen Lei wrote:
The MODULE_SOFTDEP() gives user space a hint of the loading sequence. And
when command "modprobe arm_smmuv3_pmu" is executed, the arm_smmu_v3.ko is
automatically loaded in advance.
Why do we need this? If probe order doesn't matter when both drivers are
On 29/01/2021 15:12, Robin Murphy wrote:
On 2021-01-27 11:32, Zhen Lei wrote:
The MODULE_SOFTDEP() gives user space a hint of the loading sequence. And
when command "modprobe arm_smmuv3_pmu" is executed, the arm_smmu_v3.ko is
automatically loaded in advance.
Why do we need this? If probe
Hi Linus,
The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04:
Linux 5.11-rc5 (2021-01-24 16:47:14 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.11-rc5
for you to fetch changes up to
35 matches
Mail list logo
