On 5/8/20 10:12 AM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 7, 2020 9:23 PM
Hi Kevin,
On 2020/5/7 13:45, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 7, 2020 8:56 AM
When a PASID is used for SVA by the device, it's possible that the PASID
entry is cleared before the
Hi Kevin,
On 5/7/20 2:35 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 7, 2020 8:56 AM
When a PASID is stopped or terminated, there can be pending PRQs
(requests that haven't received responses) in remapping hardware.
This adds the interface to drain page requests and call it when
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 9:23 PM
>
> Hi Kevin,
>
> On 2020/5/7 13:45, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Thursday, May 7, 2020 8:56 AM
> >>
> >> When a PASID is used for SVA by the device, it's possible that the PASID
> >> entry is cleared before the device
On 5/8/20 12:55 AM, Jacob Pan wrote:
On Thu, 7 May 2020 08:55:32 +0800
Lu Baolu wrote:
When a PASID is used for SVA by the device, it's possible that the
PASID entry is cleared before the device flushes all ongoing DMA
requests. The IOMMU should ignore the non-recoverable faults caused
by
Hi Jacob,
On 5/8/20 12:47 AM, Jacob Pan wrote:
Hi Baolu,
Very helpful feature, thanks for doing this. Just a small suggestion.
Thanks a lot for reviewing my patch.
On Thu, 7 May 2020 08:55:31 +0800
Lu Baolu wrote:
Export invalidation queue internals of each iommu device through the
On 5/8/20 12:18 AM, Andy Shevchenko wrote:
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Thanks!
Reviewed-by: Lu Baolu
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Quoting Sibi Sankar (2020-05-07 12:21:57)
> The modem remote processor has two modes of access to the DDR, a direct
> mode and through a SMMU which requires direct mapping. The configuration
> of the modem SIDs is handled in TrustZone.
Is it "The configuration of the modem SIDs is typically
The modem remote processor has two modes of access to the DDR, a direct
mode and through a SMMU which requires direct mapping. The configuration
of the modem SIDs is handled in TrustZone. On platforms where TrustZone
is absent this needs to be explicitly done from kernel. Add compatibles
for modem
On 2020-05-07 7:22 pm, Ajay kumar wrote:
On 5/7/20, Robin Murphy wrote:
On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even
On 5/7/20, Robin Murphy wrote:
> On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote:
>> From: Vijayanand Jitta
>>
>> When ever a new iova alloc request comes iova is always searched
>> from the cached node and the nodes which are previous to cached
>> node. So, even if there is free iova space
Hi Robin,
On 5/7/20, Robin Murphy wrote:
> On 2020-05-04 7:37 pm, Ajay Kumar wrote:
>> The current IOVA allocation code stores a cached copy of the
>> first allocated IOVA address node, and all the subsequent allocations
>> have no way to get past(higher than) the first allocated IOVA range.
>
>
On Thu, 7 May 2020 08:55:32 +0800
Lu Baolu wrote:
> When a PASID is used for SVA by the device, it's possible that the
> PASID entry is cleared before the device flushes all ongoing DMA
> requests. The IOMMU should ignore the non-recoverable faults caused
> by these requests.
Perhaps be more
Hi Baolu,
Very helpful feature, thanks for doing this. Just a small suggestion.
On Thu, 7 May 2020 08:55:31 +0800
Lu Baolu wrote:
> Export invalidation queue internals of each iommu device through the
> debugfs.
>
> Example of such dump on a Skylake machine:
>
> $ sudo cat
Although we can get the same information from
/sys/bus/thunderbolt/devices/domainX/iommu_dma_protection, the
IP block on the SOC may be deactivated. That means that it would
not be exported even though pre boot DMA was enabled and available.
This patch is work in progress and is only supposed to
On Tue, 5 May 2020 11:15:31 +0200
Jean-Philippe Brucker wrote:
> On Mon, May 04, 2020 at 01:47:23PM -0700, Jacob Pan wrote:
> > > > > + arm_smmu_write_ctx_desc(smmu_domain, mm->pasid,
> > > > > _cd); +
> > > > > + arm_smmu_tlb_inv_asid(smmu_domain->smmu,
> > > > > smmu_mn->cd->asid);
> >
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Signed-off-by: Andy Shevchenko
---
drivers/iommu/amd_iommu_types.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd_iommu_types.h
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Signed-off-by: Andy Shevchenko
---
drivers/iommu/iova.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
On 2020-05-07 1:06 pm, Sai Prakash Ranjan wrote:
[...]
We could have our own context fault handler in QCOM implementation,
but that would just be duplicating things from arm-smmu context fault
handler. So I did not think it makes much sense to have our own
fault handler in qcom impl just for
From: Tang Bin
[ Upstream commit b52649aee6243ea661905bdc5fbe28cc5f6dec76 ]
The function qcom_iommu_device_probe() does not perform sufficient
error checking after executing devm_ioremap_resource(), which can
result in crashes if a critical error path is encountered.
Fixes: 0ae349a0f33f
From: Suravee Suthikulpanit
[ Upstream commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 ]
Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.
Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when
From: Suravee Suthikulpanit
[ Upstream commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 ]
Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.
Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when
From: Suravee Suthikulpanit
[ Upstream commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 ]
Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.
Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when
From: Tang Bin
[ Upstream commit b52649aee6243ea661905bdc5fbe28cc5f6dec76 ]
The function qcom_iommu_device_probe() does not perform sufficient
error checking after executing devm_ioremap_resource(), which can
result in crashes if a critical error path is encountered.
Fixes: 0ae349a0f33f
From: Tang Bin
[ Upstream commit b52649aee6243ea661905bdc5fbe28cc5f6dec76 ]
The function qcom_iommu_device_probe() does not perform sufficient
error checking after executing devm_ioremap_resource(), which can
result in crashes if a critical error path is encountered.
Fixes: 0ae349a0f33f
From: Suravee Suthikulpanit
[ Upstream commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 ]
Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.
Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when
From: Suravee Suthikulpanit
[ Upstream commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 ]
Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.
Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when
On Thu, May 07, 2020 at 07:44:01PM +0530, Sibi Sankar wrote:
> On 2020-05-07 18:32, Will Deacon wrote:
> > On Tue, Apr 21, 2020 at 12:03:52AM +0530, Sai Prakash Ranjan wrote:
> > > From: Sibi Sankar
> > >
> > > The Q6 modem sub-system has direct access to DDR through memnoc.
> > > Also SMMU is
Hey WIll,
On 2020-05-07 18:32, Will Deacon wrote:
On Tue, Apr 21, 2020 at 12:03:52AM +0530, Sai Prakash Ranjan wrote:
From: Sibi Sankar
The Q6 modem sub-system has direct access to DDR through memnoc.
Also SMMU is not expected to provide access control/translation
for these SIDs (sandboxing
On Thu, 23 Apr 2020 15:25:31 +0530, Sai Prakash Ranjan wrote:
> Currently on reboot/shutdown, the following messages are
> displayed on the console as error messages before the
> system reboots/shutdown as part of remove callback.
>
> On SC7180:
>
> arm-smmu 1500.iommu: removing device
On Tue, 21 Apr 2020 00:03:48 +0530, Sai Prakash Ranjan wrote:
> This series allows DRM, Modem devices to set a default
> identity mapping in qcom smmu implementation.
>
> Patch 1 is cleanup to support other SoCs to call into
> QCOM specific implementation.
> Patch 2 sets the default identity
On 2020-05-04 7:37 pm, Ajay Kumar wrote:
The current IOVA allocation code stores a cached copy of the
first allocated IOVA address node, and all the subsequent allocations
have no way to get past(higher than) the first allocated IOVA range.
Strictly they do, after that first allocation gets
On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the
Hi Kevin,
On 2020/5/7 13:45, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 7, 2020 8:56 AM
When a PASID is used for SVA by the device, it's possible that the PASID
entry is cleared before the device flushes all ongoing DMA requests. The
IOMMU should ignore the non-recoverable faults
On Tue, Apr 21, 2020 at 12:03:52AM +0530, Sai Prakash Ranjan wrote:
> From: Sibi Sankar
>
> The Q6 modem sub-system has direct access to DDR through memnoc.
> Also SMMU is not expected to provide access control/translation
> for these SIDs (sandboxing of the modem is achieved through XPUs
>
On Thu, May 07, 2020 at 02:51:32PM +0200, Auger Eric wrote:
> Hi,
>
> On 5/7/20 1:32 PM, Michael S. Tsirkin wrote:
> > On Thu, May 07, 2020 at 11:24:29AM +, Bharat Bhushan wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Michael S. Tsirkin
> >>> Sent: Wednesday, May 6, 2020 5:53
On Thu, May 07, 2020 at 11:55:54AM +0100, Robin Murphy wrote:
> On 2020-05-07 11:14 am, Sai Prakash Ranjan wrote:
> > On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
> > > Add stall implementation hook to enable stalling
> > > faults on QCOM platforms which supports it without
> > > causing any
Hi,
On 5/6/20 2:22 AM, Michael S. Tsirkin wrote:
> On Tue, May 05, 2020 at 03:00:04PM +0530, Bharat Bhushan wrote:
>> Different endpoint can support different page size, probe
>> endpoint if it supports specific page size otherwise use
>> global page sizes.
>>
>> Signed-off-by: Bharat Bhushan
>>
Hi,
On 5/7/20 1:32 PM, Michael S. Tsirkin wrote:
> On Thu, May 07, 2020 at 11:24:29AM +, Bharat Bhushan wrote:
>>
>>
>>> -Original Message-
>>> From: Michael S. Tsirkin
>>> Sent: Wednesday, May 6, 2020 5:53 AM
>>> To: Bharat Bhushan
>>> Cc: jean-phili...@linaro.org; j...@8bytes.org;
Hi Bharat,
On 5/7/20 1:24 PM, Bharat Bhushan wrote:
>
>
>> -Original Message-
>> From: Michael S. Tsirkin
>> Sent: Wednesday, May 6, 2020 5:53 AM
>> To: Bharat Bhushan
>> Cc: jean-phili...@linaro.org; j...@8bytes.org; jasow...@redhat.com;
>> virtualizat...@lists.linux-foundation.org;
Hi Robin,
On 2020-05-07 16:25, Robin Murphy wrote:
On 2020-05-07 11:14 am, Sai Prakash Ranjan wrote:
Hi Will, Robin
On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
Add stall implementation hook to enable stalling
faults on QCOM platforms which supports it without
causing any kind of hardware
On Thu, May 07, 2020 at 11:24:29AM +, Bharat Bhushan wrote:
>
>
> > -Original Message-
> > From: Michael S. Tsirkin
> > Sent: Wednesday, May 6, 2020 5:53 AM
> > To: Bharat Bhushan
> > Cc: jean-phili...@linaro.org; j...@8bytes.org; jasow...@redhat.com;
> >
> -Original Message-
> From: Michael S. Tsirkin
> Sent: Wednesday, May 6, 2020 5:53 AM
> To: Bharat Bhushan
> Cc: jean-phili...@linaro.org; j...@8bytes.org; jasow...@redhat.com;
> virtualizat...@lists.linux-foundation.org; iommu@lists.linux-foundation.org;
>
The Arm SMMUv1 DT binding only allows combining arm,mmu-401 with
arm,smmu-v1, even though the MMU-400 is compatible as well.
Allow this combination as well to let the Arm Juno board pass the test.
Signed-off-by: Andre Przywara
Acked-by: Robin Murphy
---
Hi Will,
On 2020-05-07 16:01, Will Deacon wrote:
On Thu, May 07, 2020 at 03:58:06PM +0530, Sai Prakash Ranjan wrote:
Hi Will, Joerg
On 2020-04-21 00:03, Sai Prakash Ranjan wrote:
> This series allows DRM, Modem devices to set a default
> identity mapping in qcom smmu implementation.
>
> Patch
On 2020-05-07 16:03, Robin Murphy wrote:
On 2020-05-07 11:04 am, Sai Prakash Ranjan wrote:
Hi,
On 2020-05-07 05:40, Doug Anderson wrote:
Hi,
On Thu, Apr 23, 2020 at 7:35 AM Doug Anderson
wrote:
Hi,
On Thu, Apr 23, 2020 at 2:55 AM Sai Prakash Ranjan
wrote:
>
> Currently on
On 2020-05-07 11:14 am, Sai Prakash Ranjan wrote:
Hi Will, Robin
On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
Add stall implementation hook to enable stalling
faults on QCOM platforms which supports it without
causing any kind of hardware mishaps. Without this
on QCOM platforms, GPU faults
On 2020-05-07 11:04 am, Sai Prakash Ranjan wrote:
Hi,
On 2020-05-07 05:40, Doug Anderson wrote:
Hi,
On Thu, Apr 23, 2020 at 7:35 AM Doug Anderson
wrote:
Hi,
On Thu, Apr 23, 2020 at 2:55 AM Sai Prakash Ranjan
wrote:
>
> Currently on reboot/shutdown, the following messages are
> displayed
On Thu, May 07, 2020 at 03:58:06PM +0530, Sai Prakash Ranjan wrote:
> Hi Will, Joerg
>
> On 2020-04-21 00:03, Sai Prakash Ranjan wrote:
> > This series allows DRM, Modem devices to set a default
> > identity mapping in qcom smmu implementation.
> >
> > Patch 1 is cleanup to support other SoCs to
Hi Will, Joerg
On 2020-04-21 00:03, Sai Prakash Ranjan wrote:
This series allows DRM, Modem devices to set a default
identity mapping in qcom smmu implementation.
Patch 1 is cleanup to support other SoCs to call into
QCOM specific implementation.
Patch 2 sets the default identity domain for
Hi Will, Robin
On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
Add stall implementation hook to enable stalling
faults on QCOM platforms which supports it without
causing any kind of hardware mishaps. Without this
on QCOM platforms, GPU faults can cause unrelated
GPU memory accesses to return
Hi,
On 2020-05-07 05:40, Doug Anderson wrote:
Hi,
On Thu, Apr 23, 2020 at 7:35 AM Doug Anderson
wrote:
Hi,
On Thu, Apr 23, 2020 at 2:55 AM Sai Prakash Ranjan
wrote:
>
> Currently on reboot/shutdown, the following messages are
> displayed on the console as error messages before the
>
Hi Marek,
On 05/05/2020 10:45, Marek Szyprowski wrote:
> struct sg_table is a common structure used for describing a memory
> buffer. It consists of a scatterlist with memory pages and DMA addresses
> (sgl entry), as well as the number of scatterlist entries: CPU pages
> (orig_nents entry) and
Hi Shameer,
On 5/7/20 8:59 AM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Shameerali Kolothum Thodi
>> Sent: 30 April 2020 10:38
>> To: 'Auger Eric' ; Zhangfei Gao
>> ; eric.auger@gmail.com;
>> iommu@lists.linux-foundation.org;
Hi Eric,
> -Original Message-
> From: Shameerali Kolothum Thodi
> Sent: 30 April 2020 10:38
> To: 'Auger Eric' ; Zhangfei Gao
> ; eric.auger@gmail.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu;
Hi Kevin,
Thanks a lot for reviewing.
On 2020/5/7 14:38, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 7, 2020 8:55 AM
When a PASID is stopped or terminated, there can be pending PRQs
(requests that haven't received responses) in the software and
remapping hardware. The pending page
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:55 AM
>
> When a PASID is stopped or terminated, there can be pending PRQs
> (requests that haven't received responses) in the software and
> remapping hardware. The pending page requests must be drained
> so that the pasid could be reused. The
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> IOTLB flush already included in the PASID tear down and the page request
> drain process. There is no need to flush again.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-svm.c | 6 +-
> 1 file
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> When a PASID is stopped or terminated, there can be pending PRQs
> (requests that haven't received responses) in remapping hardware.
> This adds the interface to drain page requests and call it when a
> PASID is terminated.
>
>
59 matches
Mail list logo
