From: Yuqi Jin
The performance of the atomic_xchg is better than atomic_cmpxchg because
no comparison is required. While the value of @fq_timer_on can only be 0
or 1. Let's use atomic_xchg instead of atomic_cmpxchg here because we
only need to check that the value changes from 0 to 1 or from 1
On 26/08/2020 10:56, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards
This fixed the below checkpatch issue:
WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using
octal permissions '0444'.
417: FILE: drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:417:
module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
Reviewed-by: Robin Murphy
patch 1/3 and patch 2/3 are the preparation of patch 3/3 which permits users
to disable MSI-based polling by cmd line.
-v5:
add Robin's reviewed-by
-v4:
with respect to Robin's comments
* cleanup the code of the existing module parameter disable_bypass
* add ARM_SMMU_OPT_MSIPOLL flag. on
Polling by MSI isn't necessarily faster than polling by SEV. Tests on
hi1620 show hns3 100G NIC network throughput can improve from 25G to
27G if we disable MSI polling while running 16 netperf threads sending
UDP packets in size 32KB. TX throughput can improve from 7G to 7.7G for
single thread.
Just use module_param() - going out of the way to specify a "different"
name that's identical to the variable name is silly.
Reviewed-by: Robin Murphy
Signed-off-by: Barry Song
---
-v5: add Robin's reviewed-by
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +-
1 file changed, 1
Hi David,
On Mon, Jul 13, 2020 at 10:36 PM Lad Prabhakar
wrote:
>
> From: Marian-Cristian Rotariu
>
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
> ---
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
>
On 2020-08-26 12:17, Thomas Gleixner wrote:
MSI interrupts have some common flags which should be set not only for
PCI/MSI interrupts.
Move the PCI/MSI flag setting into a common function so it can be
reused.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/pci/msi.c |7
cmdq_issue_cmdlist() is the hotspot that uses a lot of time. This patch
adds tracepoints for it to help debug.
Signed-off-by: Barry Song
---
* can furthermore develop an eBPF program to benchmark using this trace
cmdlistlat.c:
#include
BPF_HASH(start, u32);
BPF_HISTOGRAM(dist);
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 76
BIOS allocate reserved memory ranges that may be DMA targets.
BIOS may report each such reserved memory region through the
RMRR structures,along with the devices that requires access to
the specified reserved memory region.
The purpose of this series is to achieve ACPI device in RMRR
access
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the RMRR region.
Signed-off-by: FelixCuioc
---
On 27/08/2020 14:31, Frank Wunderlich wrote:
Tested full series on bananapi r2 (mt7623/mt2701, 5.9-rc1 + hdmi-patches),
works so far fbcon+x without issues
Tested-by: Frank Wunderlich
Thanks for testing.
Robin this is especially relevant for:
[PATCH 09/18] iommu/mediatek-v1: Add
Tested full series on bananapi r2 (mt7623/mt2701, 5.9-rc1 + hdmi-patches),
works so far fbcon+x without issues
Tested-by: Frank Wunderlich
regards Frank
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote:
>
> On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> > Hi,
> >
> > On 8/24/2020 12:30 PM, Jim Quinlan wrote:
> >>
> >> Patchset Summary:
> >>Enhance a PCIe host controller driver. Because of its unusual design
> >>
If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
table, we could default to the device NUMA domain as fall back. This also
benefits the vIOMMU use case where only a single vIOMMU is exposed, hence
no RHSA will be present but device numa domain can be correct.
Cc: Jacob Pan
On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> Hi,
>
> On 8/24/2020 12:30 PM, Jim Quinlan wrote:
>>
>> Patchset Summary:
>>Enhance a PCIe host controller driver. Because of its unusual design
>>we are foced to change dev->dma_pfn_offset into a more general role
>>
On 26.08.20 13:16, Thomas Gleixner wrote:
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
phys_addr_t can be 32-bit, in which case smatch will complain:
kernel/dma/pool.c:79 cma_in_zone() warn: always true condition '(end <= 32)
== 64)) ?~0:((1 << (32)) - 1))) => (0-u32max <= u32max)'
Just turn the variable into a u64 to make the range check valid.
Fixes: d7e673ec2c8e
24.08.2020 17:01, Robin Murphy пишет:
...
>> Robin, thank you very much for the clarifications!
>>
>> In accordance to yours comments, this patch can't be applied until Tegra
>> SMMU will support IOMMU_DOMAIN_IDENTITY and implement def_domain_type()
>> callback that returns IOMMU_DOMAIN_IDENTITY
On Wed, Aug 26, 2020 at 09:26:02AM -0400, Michael S. Tsirkin wrote:
> On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote:
> > Add a topology description to the virtio-iommu driver and enable x86
> > platforms.
> >
> > Since [v2] we have made some progress on adding ACPI support
Thanks,
applied to the dma-mapping for-linux tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 26.08.20 13:16, Thomas Gleixner wrote:
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into
On Thu, Aug 20, 2020 at 04:08:32PM +0100, Robin Murphy wrote:
> Now that arch/arm is wired up for default domains and iommu-dma,
> implement the corresponding driver-side support for DMA domains.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/tegra-smmu.c | 37
On Thu, Aug 27, 2020 at 10:05:14AM +0300, Dmitry Osipenko wrote:
> 24.08.2020 17:01, Robin Murphy пишет:
> ...
> >> Robin, thank you very much for the clarifications!
> >>
> >> In accordance to yours comments, this patch can't be applied until Tegra
> >> SMMU will support IOMMU_DOMAIN_IDENTITY and
Hi Jacob,
On 8/24/20 12:32 PM, Jean-Philippe Brucker wrote:
> On Fri, Aug 21, 2020 at 09:35:10PM -0700, Jacob Pan wrote:
>> IOASID is used to identify address spaces that can be targeted by device
>> DMA. It is a system-wide resource that is essential to its many users.
>> This document is an
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and a kernel-user transition to notify the
hardware of new work. What if both the translation and transition overhead
could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify process
address space and direct responses to the right address space.
Signed-off-by: Fenghua
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v4:
- Change PASID type to u32 (Christoph)
v3:
-
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
-
Currently the ENQCMD feature cannot be used if CONFIG_INTEL_IOMMU_SVM
is not set. Add X86_FEATURE_ENQCMD to the disabled features mask.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v7:
- Split this patch from a previous patch.
arch/x86/include/asm/disabled-features.h | 9 -
1
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in
Hi Linus and Bartosz,
On Mon, Jul 13, 2020 at 10:35 PM Lad Prabhakar
wrote:
>
> Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
> relevant dt-bindings.
>
> Signed-off-by: Lad Prabhakar
> ---
> Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 1 +
> 1 file
On Wed, Aug 26, 2020 at 01:16:29PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Dereferencing irq_data before checking it for NULL is suboptimal.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Joerg Roedel
Reviewed-by: Joerg Roedel
___
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
Reviewed-by: Lu Baolu
---
v5:
- Reviewed by Lu Baolu
v2:
- Add this
A PASID is allocated for an "mm" the first time any thread binds
to an SVM capable device and is freed from the "mm" when the SVM is
unbound by the last thread. It's possible for the "mm" to have different
PASID values in different binding/unbinding SVM cycles.
The mm's PASID (non-zero for valid
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".
No PASID type change
On 2020-08-27 06:31, Yong Wu wrote:
On Wed, 2020-08-26 at 16:56 +0800, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the
On 2020-08-27 09:43, Shaokun Zhang wrote:
From: Yuqi Jin
The performance of the atomic_xchg is better than atomic_cmpxchg because
no comparison is required. While the value of @fq_timer_on can only be 0
or 1. Let's use atomic_xchg instead of atomic_cmpxchg here because we
only need to check
On 2020-08-27 16:45, Thierry Reding wrote:
On Thu, Aug 20, 2020 at 04:08:32PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
[+cc Rob,
cover https://lore.kernel.org/r/20200826111628.794979...@linutronix.de/
this https://lore.kernel.org/r/20200826112333.992429...@linutronix.de/]
On Wed, Aug 26, 2020 at 01:17:02PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled
Hi,
On 8/27/20 1:39 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, August 27, 2020 12:25 PM
The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
General
Description) that:
If multiple control fields in this register need to be modified, software
must serialize the
The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG General
Description) that:
If multiple control fields in this register need to be modified, software
must serialize the modifications through multiple writes to this register.
However, in irq_remapping.c, modifications of IRE and
Hi Thomas,
On 8/26/2020 1:50 PM, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 20:32, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 09:50, Megha Dey wrote:
@@ -329,15 +329,15 @@ static struct irq_chip dmar_msi_controll
static irq_hw_number_t dmar_msi_get_hwirq(struct msi_domain_info *info,
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
From: Thomas Gleixner
To support MSI irq domains which do not fit at all into the regular MSI
irqdomain scheme, like the XEN MSI interrupt management for PV/HVM/DOM0,
it's necessary to allow to override the alloc/free implementation.
> From: Lu Baolu
> Sent: Friday, August 28, 2020 8:06 AM
>
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
>
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple writes
Hi Lad-san,
> From: Lad Prabhakar, Sent: Tuesday, August 25, 2020 11:18 PM
>
> Document RZ/G1H (R8A7742) SoC bindings.
>
> No driver change is needed due to the fallback compatible value
> "renesas,ipmmu-vmsa".
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Chris Paterson
> ---
Thank you
On Thu, 27 Aug 2020 at 22:36, Logan Gunthorpe wrote:
>
>
>
> On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> > I have added a check for the sg_dma_len == 0 :
> > """
> > } __sgt_iter(struct scatterlist *sgl, bool dma) {
> > struct sgt_iter s = { .sgp = sgl };
> >
> > + if (sgl &&
On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
>
> if (s.sgp)
On Thu, Aug 27, 2020 at 6:40 PM Lad, Prabhakar
wrote:
>
> Hi Linus and Bartosz,
>
> On Mon, Jul 13, 2020 at 10:35 PM Lad Prabhakar
> wrote:
> >
> > Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
> > relevant dt-bindings.
> >
> > Signed-off-by: Lad Prabhakar
> > ---
> >
> From: Lu Baolu
> Sent: Thursday, August 27, 2020 1:57 PM
>
> If there are multiple NUMA domains but the RHSA is missing in ACPI/DMAR
> table, we could default to the device NUMA domain as fall back. This also
> benefits the vIOMMU use case where only a single vIOMMU is exposed,
> hence
> no
52 matches
Mail list logo
