On Thu, May 13, 2021 at 03:58:15PM +0800, Zhen Lei wrote:
> Function iommu_group_store_type() is the only caller of the static
> function iommu_change_dev_def_domain() and has performed
> "if (WARN_ON(!group))" detection before calling it. So the one here is
> redundant.
>
> Signed-off-by: Zhen
On 5/30/21 3:50 PM, Parav Pandit wrote:
Hi David, Lu,
This short series contains small cleanup patches for Intel iommu
in DMAR area.
Patch summary:
Patch-1 uses bitfields for few DMAR capabilities
Patch-2 removes unused iommu_count
Patch-3 removed unnecessary braces
Patch-4 define count data
Hi Kevin,
On 6/7/21 4:58 AM, Tian, Kevin wrote:
> Hi, all,
>
> We plan to work on v2 now, given many good comments already received
> and substantial changes envisioned. This is a very complex topic with
> many sub-threads being discussed. To ensure that I didn't miss valuable
> suggestions (and
On 5/23/21 10:32 PM, Aditya Srivastava wrote:
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
The header for drivers/iommu/intel/pasid.c follows this syntax, but
the content inside does not comply with kernel-doc.
This line was probably not meant
On 4/17/21 1:18 AM, Colin King wrote:
From: Colin Ian King
The variable agaw is initialized with a value that is never
read and it is being updated later with a new value as a
counter in a for-loop. The initialization is redundant and
can be removed.
Addresses-Coverity: ("Unused value")
On 5/28/21 9:02 PM, YueHaibing wrote:
Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(),
which makes the code a bit shorter and easier to read.
Signed-off-by: YueHaibing
Queued for v5.14. Thanks!
Best regards,
baolu
___
iommu mailing list
On Fri, Jun 04, 2021 at 06:44:37PM +0200, Benjamin Gaignard wrote:
> This series adds the IOMMU driver for rk356x SoC.
> Since a new compatible is needed to distinguish this second version of
> IOMMU hardware block from the first one, it is an opportunity to convert
> the binding to DT schema.
>
On 5/27/21 7:35 AM, Kyung Min Park wrote:
When the dmar translation fault happens, the kernel prints a single line
fault reason with corresponding hexadecimal code defined in the Intel VT-d
specification.
Currently, when user wants to debug the translation fault in detail,
debugfs is used for
Fix some spelling mistakes in comments found by "codespell":
detroyed ==> destroyed
defered ==> deferred
entrie ==> entry
alloced ==> allocated
regularily ==> regularly
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 2 +-
include/linux/iova.h | 10 +-
2 files changed, 6
Fix some spelling mistakes in comments found by "codespell":
alignement ==> alignment
implemtation ==> implementation
assignement ==> assignment
initally ==> initially
Returs ==> Returns
Traverese ==> Traverse
guarentees ==> guarantees
resgister ==> register
insufficent ==> insufficient
v2 --> v3:
1) Add some new fixes for the latest linux-next:
drivers/iommu/fsl_pamu_domain.c:366: Traverese ==> Traverse
drivers/iommu/mtk_iommu.c:977: Uppon ==> Upon
drivers/iommu/intel/svm.c:488: shuld ==> should
drivers/iommu/intel/svm.c:920: requeset ==> request
> From: Eric Auger
> Sent: Wednesday, June 9, 2021 4:15 PM
>
> Hi Kevin,
>
> On 6/7/21 4:58 AM, Tian, Kevin wrote:
> > Hi, all,
> >
> > We plan to work on v2 now, given many good comments already received
> > and substantial changes envisioned. This is a very complex topic with
> > many
On 4/15/21 4:14 AM, Gustavo A. R. Silva wrote:
Replace a couple of calls to memcpy() with simple assignments in order
to fix the following out-of-bounds warning:
drivers/iommu/intel/svm.c:1198:4: warning: 'memcpy' offset [25, 32] from the
object at 'desc' is out of the bounds of referenced
Hi John,
On Tue, Jun 08, 2021 at 09:18:25PM +0800, John Garry wrote:
> Zhen Lei (3):
> iommu: Enhance IOMMU default DMA mode build options
> iommu/vt-d: Add support for IOMMU default DMA mode build options
> iommu/amd: Add support for IOMMU default DMA mode build options
So I like the
On 08.06.21 21:00, Jason Gunthorpe wrote:
Eg I can do open() on a file and I get to keep that FD. I get to keep
that FD even if someone later does chmod() on that file so I can't
open it again.
There are lots of examples where a one time access control check
provides continuing access to a
On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> Hi, all,
<...>
> (Remaining opens in v1)
<...>
> - Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully
> convinced yet. Based on discussion v2 will continue to have ioasid uAPI
> being device-centric
On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
On 08.06.21 21:00, Jason Gunthorpe wrote:
Eg I can do open() on a file and I get to keep that FD. I get to keep
that FD even if someone later does chmod() on that file so I can't
open it again.
There are lots of examples where a one
On Tue, Jun 08, 2021 at 12:42:34PM +0100, Will Deacon wrote:
> On Wed, 26 May 2021 18:19:25 +0200, Jean-Philippe Brucker wrote:
> > Add stall support for SMMUv3, enabling I/O page faults and SVA for
> > compatible devices. No change since last version [1], but I'd still like
> > this to be
> From: Leon Romanovsky
> Sent: Wednesday, June 9, 2021 5:02 PM
>
> On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> > Hi, all,
>
> <...>
>
> > (Remaining opens in v1)
>
> <...>
>
> > - Device-centric (Jason) vs. group-centric (David) uAPI. David is not
> > fully
> >
Hi Kevin,
On 6/9/21 11:37 AM, Tian, Kevin wrote:
>> From: Eric Auger
>> Sent: Wednesday, June 9, 2021 4:15 PM
>>
>> Hi Kevin,
>>
>> On 6/7/21 4:58 AM, Tian, Kevin wrote:
>>> Hi, all,
>>>
>>> We plan to work on v2 now, given many good comments already received
>>> and substantial changes
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> Last unclosed open. Jason, you dislike symbol_get in this contract per
> earlier comment. As Alex explained, looks it's more about module
> dependency which is orthogonal to how this contract is designed. What
> is your opinion now?
On 07/06/2021 10:49, Krzysztof Kozlowski wrote:
> Hi Olof and Arnd,
>
> Tegra memory controller driver changes with necessary dependency from Thierry
> (which you will also get from him):
> 1. Dmitry's power domain work on Tegra MC drivers,
> 2. Necessary clock and regulator dependencies for
On Wed, Jun 09, 2021 at 02:24:03PM +0200, Joerg Roedel wrote:
> On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> > - Device-centric (Jason) vs. group-centric (David) uAPI. David is not
> > fully
> > convinced yet. Based on discussion v2 will continue to have ioasid uAPI
> >
On Sun, May 30, 2021 at 11:06:18AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V exposes GHCB page via SEV ES GHCB MSR for SNP guest
> to communicate with hypervisor. Map GHCB page for all
> cpus to read/write MSR register and submit hvcall request
> via GHCB.
>
> Signed-off-by:
On Sun, May 30, 2021 at 11:06:21AM -0400, Tianyu Lan wrote:
> +void hv_ghcb_msr_write(u64 msr, u64 value)
> +{
> + union hv_ghcb *hv_ghcb;
> + void **ghcb_base;
> + unsigned long flags;
> +
> + if (!ms_hyperv.ghcb_base)
> + return;
> +
> + local_irq_save(flags);
> +
On 09/06/21 13:57, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
Last unclosed open. Jason, you dislike symbol_get in this contract per
earlier comment. As Alex explained, looks it's more about module
dependency which is orthogonal to how this contract is
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
On Wed, Jun 09, 2021 at 11:11:17AM +0200, Paolo Bonzini wrote:
> On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
> > On 08.06.21 21:00, Jason Gunthorpe wrote:
> >
> > > Eg I can do open() on a file and I get to keep that FD. I get to keep
> > > that FD even if someone later does
On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
> On 09/06/21 13:57, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> >
> > > Last unclosed open. Jason, you dislike symbol_get in this contract per
> > > earlier comment. As Alex explained,
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei
---
drivers/iommu/ipmmu-vmsa.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
On 10/04/2021 11:11, Yong Wu wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> This patch use pm_runtime_resume_and_get instead of pm_runtime_get
> to keep usage counter balanced.
>
> CC: Xia Jiang
> Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
>
On Wed, Jun 09, 2021 at 03:24:11PM +0200, Paolo Bonzini wrote:
> On 09/06/21 14:47, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
> > > On 09/06/21 13:57, Jason Gunthorpe wrote:
> > > > On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> > > >
On Wed, 9 Jun 2021 08:54:45 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 09, 2021 at 11:11:17AM +0200, Paolo Bonzini wrote:
> > On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
> > > On 08.06.21 21:00, Jason Gunthorpe wrote:
> > >
> > > > Eg I can do open() on a file and I get to
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei
---
drivers/iommu/intel/dmar.c | 2 --
drivers/iommu/intel/iommu.c | 6 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff
On Sun, May 30, 2021 at 11:06:22AM -0400, Tianyu Lan wrote:
> +u64 hv_ghcb_hypercall(u64 control, void *input, void *output, u32 input_size)
> +{
> + union hv_ghcb *hv_ghcb;
> + void **ghcb_base;
> + unsigned long flags;
> +
> + if (!ms_hyperv.ghcb_base)
> + return
On Wed, Jun 09, 2021 at 09:39:19AM -0300, Jason Gunthorpe wrote:
> VFIO being group centric has made it very ugly/difficult to inject
> device driver specific knowledge into the scheme.
This whole API will be complicated and difficult anyway, so no reason to
unnecessarily simplify things here.
On 09/06/21 14:47, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
On 09/06/21 13:57, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
Last unclosed open. Jason, you dislike symbol_get in this contract per
earlier
arm_smmu_rpm_get() invokes pm_runtime_get_sync(), which increases the
refcount of the "smmu" even though the return value is less than 0.
The reference counting issue happens in several exception handling paths
of arm_smmu_iova_to_phys_hard(). When those error scenarios occur, the
function
arm_smmu_rpm_get() invokes pm_runtime_get_sync(), which increases the
refcount of the "smmu" even though the return value is less than 0.
The reference counting issue happens in some error handling paths of
arm_smmu_rpm_get() in its caller functions. When arm_smmu_rpm_get()
fails, the caller
On 2021-06-09 14:35, Xiyu Yang wrote:
arm_smmu_rpm_get() invokes pm_runtime_get_sync(), which increases the
refcount of the "smmu" even though the return value is less than 0.
The reference counting issue happens in some error handling paths of
arm_smmu_rpm_get() in its caller functions. When
On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> - Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully
> convinced yet. Based on discussion v2 will continue to have ioasid uAPI
> being device-centric (but it's fine for vfio to be group-centric). A new
On 10/04/2021 11:11, Yong Wu wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> This patch use pm_runtime_resume_and_get instead of pm_runtime_get
> to keep usage counter balanced.
>
> Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
>
On Wed, Jun 09, 2021 at 03:32:34PM +0200, Joerg Roedel wrote:
> > The group is causing all this mess because the group knows nothing
> > about what the device drivers contained in the group actually want.
>
> There are devices in the group, not drivers.
Well exactly, that is the whole problem.
On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote:
> Only *drivers* know what the actual device is going to do, devices do
> not. Since the group doesn't have drivers it is the wrong layer to be
> making choices about how to configure the IOMMU.
Groups don't carry how to configure
On 09/06/21 16:45, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote:
If we go back to the wbinvd ioctl mechanism, if I call that ioctl with
an ioasidfd that contains no devices, then I shouldn't be able to
generate a wbinvd on the processor, right? If I
Currently for iommu_unmap() of large scatter-gather list with page size
elements, the majority of time is spent in flushing of partial walks in
__arm_lpae_unmap() which is a VA based TLB invalidation (TLBIVA for
arm-smmu).
For example: to unmap a 32MB scatter-gather list with page size elements
On 2021-06-08 14:18, John Garry wrote:
From: Zhen Lei
First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the two config options in a choice, as they are mutually exclusive.
[jpg: Make choice
On Wed, 9 Jun 2021 17:51:26 +0200
Joerg Roedel wrote:
> On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote:
> > Only *drivers* know what the actual device is going to do, devices do
> > not. Since the group doesn't have drivers it is the wrong layer to be
> > making choices about
On 10/04/2021 11:11, Yong Wu wrote:
> After adding device_link between the iommu consumer and smi-larb,
> the pm_runtime_get(_sync) of smi-larb and smi-common will be called
> automatically. we can get rid of mtk_smi_larb_get/put.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
>
>> I've told Fenghua to dig out the previous iteration of this patch where
>> the plan was to lazily fix the PASID_MSR in other threads in the #GP
>> handler.
>
> Blech. Also this won't work for other PASID-like features.
>
> I have a half-written patch to fix this up for real. Stay tuned.
On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote:
> If we go back to the wbinvd ioctl mechanism, if I call that ioctl with
> an ioasidfd that contains no devices, then I shouldn't be able to
> generate a wbinvd on the processor, right? If I add a device,
> especially in a
On 09/06/2021 16:03, Robin Murphy wrote:
On 2021-06-08 14:18, John Garry wrote:
From: Zhen Lei
First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the two config options in a choice, as they are
On Wed, 9 Jun 2021 10:15:32 -0600
Alex Williamson wrote:
> On Wed, 9 Jun 2021 17:51:26 +0200
> Joerg Roedel wrote:
>
> > On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote:
> > > Only *drivers* know what the actual device is going to do, devices do
> > > not. Since the group
在 2021/6/10 上午10:00, Jason Wang 写道:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already
worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
Domain is getting created more than once during asynchronous multiple
display heads(devices) probe. All the display heads share same SID and
are expected to be in same domain. As iommu_alloc_default_domain() call
is not protected, the group->default_domain and group->domain are ending
up with
From: Krishna Reddy
iommu_group is getting created more than once during asynchronous multiple
display heads(devices) probe on Tegra194 SoC. All the display heads share
same SID and are expected to be in same iommu_group.
As arm_smmu_device_group() is not protecting group creation across
Fix races during iommu group/domain creation for devices sharing same SID.
Ashish Mhetre (1):
iommu: Fix race condition during default domain allocation
Krishna Reddy (1):
iommu/arm-smmu: Fix race condition during iommu_group creation
drivers/iommu/arm/arm-smmu/arm-smmu.c | 6 +-
Thanks for your advice, I'll send a v2 patch soon.
> -Original Messages-
> From: "Robin Murphy"
> Sent Time: 2021-06-09 22:12:11 (Wednesday)
> To: "Xiyu Yang" , "Will Deacon" ,
> "Joerg Roedel" , "Nicolin Chen" ,
> "Bjorn Andersson" , "Krishna Reddy"
> , "Jordan Crouse" , "Sai
Hi Robin,
On 2021-06-10 00:14, Robin Murphy wrote:
On 2021-06-09 15:53, Sai Prakash Ranjan wrote:
Currently for iommu_unmap() of large scatter-gather list with page
size
elements, the majority of time is spent in flushing of partial walks
in
__arm_lpae_unmap() which is a VA based TLB
On 6/9/21 8:39 PM, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:24:03PM +0200, Joerg Roedel wrote:
On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
- Device-centric (Jason) vs. group-centric (David) uAPI. David is not fully
convinced yet. Based on discussion v2 will
On 2021-06-09 15:53, Sai Prakash Ranjan wrote:
Currently for iommu_unmap() of large scatter-gather list with page size
elements, the majority of time is spent in flushing of partial walks in
__arm_lpae_unmap() which is a VA based TLB invalidation (TLBIVA for
arm-smmu).
For example: to unmap a
On Wed, 9 Jun 2021 02:49:32 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, June 9, 2021 2:47 AM
> >
> > On Tue, 8 Jun 2021 15:44:26 +0200
> > Paolo Bonzini wrote:
> >
> > > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > > On Tue, Jun 08, 2021 at 09:56:09AM
On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
> > > It is a kernel decision, because a fundamental task of the kernel is to
> > > ensure isolation between user-space tasks as good as it can. And if a
> > > device assigned to one task can interfer with a device of another task
>
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
structued events back?
Actually it
Hi Joerg,
The patches queued in this series are for v5.14.
It includes:
- Convert Intel IOMMU to use sva_lib helpers in iommu core
- ftrace and debugfs supports for page fault handling
- Support asynchronous nested capabilities
- Various misc cleanups
Please pull.
Best regards,
Baolu
From: Colin Ian King
The variable agaw is initialized with a value that is never read and it
is being updated later with a new value as a counter in a for-loop. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
Signed-off-by:
From: Aditya Srivastava
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
The header for drivers/iommu/intel/pasid.c follows this syntax, but
the content inside does not comply with kernel-doc.
This line was probably not meant for kernel-doc parsing,
The Intel IOMMU driver reports the DMA fault reason in a decimal number
while the VT-d specification uses a hexadecimal one. It's inconvenient
that users need to covert them everytime before consulting the spec.
Let's use hexadecimal number for a DMA fault reason.
The fault message uses
The Intel VT-d implementation supports device TLB management. Select
PCI_ATS explicitly so that the pci_ats helpers are always available.
Signed-off-by: Lu Baolu
Acked-by: Will Deacon
Link:
https://lore.kernel.org/r/20210512065313.3441309-1-baolu...@linux.intel.com
---
Current VT-d implementation supports nested translation only if all
underlying IOMMUs support the nested capability. This is unnecessary
as the upper layer is allowed to create different containers and set
them with different type of iommu backend. The IOMMU driver needs to
guarantee that devices
We are about to use iommu_sva_alloc/free_pasid() helpers in iommu core.
That means the pasid life cycle will be managed by iommu core. Use a
local array to save the per pasid private data instead of attaching it
the real pasid.
Signed-off-by: Lu Baolu
Link:
Align the pasid alloc/free code with the generic helpers defined in the
iommu core. This also refactored the SVA binding code to improve the
readability.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
include/linux/intel-iommu.h |
It's common to iterate the svm device list and find a matched device. Add
common helpers to do this and consolidate the code.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
drivers/iommu/intel/svm.c | 68
Refactor prq_event_thread() by moving handling single prq event out of
the main loop.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
drivers/iommu/intel/svm.c | 239 ++
1 file changed, 136
This allocates and registers the iopf queue infrastructure for devices
which want to support IO page fault for SVA.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
include/linux/intel-iommu.h | 2 ++
drivers/iommu/intel/iommu.c | 66
This adds a new trace event to track the page fault request report.
This event will provide almost all information defined in a page
request descriptor.
A sample output:
| prq_report: dmar0/:00:0a.0 seq# 1: rid=0x50 addr=0x559ef6f97 r
pasid=0x2 index=0x1
| prq_report: dmar0/:00:0a.0
The execution time of some operations is very performance critical, such
as cache invalidation and PRQ processing time. This adds some common code
to monitor the execution time range of those operations. The interfaces
include enabling/disabling, checking status, updating sampling data and
A debugfs interface /sys/kernel/debug/iommu/intel/dmar_perf_latency is
created to control and show counts of execution time ranges for various
types per DMAR. The interface may help debug any potential performance
issue.
By default, the interface is disabled.
Possible write value of
Queued invalidation execution time is performance critical and needs
to be monitored. This adds code to sample the execution time of IOTLB/
devTLB/ICE cache invalidation.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
Let the IO page fault requests get handled through the io-pgfault
framework.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
drivers/iommu/intel/iommu.c | 14 ++-
drivers/iommu/intel/svm.c | 84
The execution time for page fault request handling is performance critical
and needs to be monitored. This adds code to sample the execution time of
page fault request handling.
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210520031531.712333-1-baolu...@linux.intel.com
---
From: "Gustavo A. R. Silva"
Replace a couple of calls to memcpy() with simple assignments in order
to fix the following out-of-bounds warning:
drivers/iommu/intel/svm.c:1198:4: warning: 'memcpy' offset [25, 32] from
the object at 'desc' is out of the bounds of referenced subobject
'qw2'
From: YueHaibing
Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(),
which makes the code a bit shorter and easier to read.
Signed-off-by: YueHaibing
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210528130229.22108-1-yuehaib...@huawei.com
---
drivers/iommu/intel/iommu.c |
From: Parav Pandit
IOTLB device presence, iommu coherency and snooping are boolean
capabilities. Use them as bits and keep them adjacent.
Structure layout before the reorg.
$ pahole -C dmar_domain drivers/iommu/intel/dmar.o
struct dmar_domain {
intnid;
From: Parav Pandit
No need for braces for single line statement under if() block.
Signed-off-by: Parav Pandit
Signed-off-by: Lu Baolu
Link: https://lore.kernel.org/r/20210530075053.264218-1-pa...@nvidia.com
---
drivers/iommu/intel/iommu.c | 3 +--
1 file changed, 1 insertion(+), 2
From: Parav Pandit
DMAR domain uses per DMAR refcount. It is indexed by iommu seq_id.
Older iommu_count is only incremented and decremented but no decisions
are taken based on this refcount. This is not of much use.
Hence, remove iommu_count and further simplify domain_detach_iommu()
by
From: Parav Pandit
Avoid below checkpatch warning.
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
+ unsignediommu_refcnt[DMAR_UNITS_SUPPORTED];
Fixes: 29a27719abaa ("iommu/vt-d: Replace iommu_bmp with a refcount")
Signed-off-by: Parav Pandit
Signed-off-by: Lu Baolu
From: Parav Pandit
Page directory assignment by alloc_pgtable_page() or phys_to_virt()
doesn't need typecasting as both routines return void*. Hence, remove
typecasting from both the calls.
Signed-off-by: Parav Pandit
Signed-off-by: Lu Baolu
Link:
在 2021/6/8 下午6:45, Enrico Weigelt, metux IT consult 写道:
On 07.06.21 20:01, Jason Gunthorpe wrote:
it is what it is, select has a fixed size bitmap of FD #s and
a hard upper bound on that size as part of the glibc ABI - can't be
fixed.
in glibc ABI ? Uuuuh!
Note that dealing with select()
The reference counting issue happens in several exception handling paths
of arm_smmu_iova_to_phys_hard(). When those error scenarios occur, the
function forgets to decrease the refcount of "smmu" increased by
arm_smmu_rpm_get(), causing a refcount leak.
Fix this issue by jumping to "out" label
arm_smmu_rpm_get() invokes pm_runtime_get_sync(), which increases the
refcount of the "smmu" even though the return value is less than 0.
The reference counting issue happens in some error handling paths of
arm_smmu_rpm_get() in its caller functions. When arm_smmu_rpm_get()
fails, the caller
On 6/9/21 10:32 AM, Luck, Tony wrote:
>>> I've told Fenghua to dig out the previous iteration of this patch where
>>> the plan was to lazily fix the PASID_MSR in other threads in the #GP
>>> handler.
>>
>> Blech. Also this won't work for other PASID-like features.
>>
>> I have a half-written
93 matches
Mail list logo
