On Tue, May 10, 2022 at 04:00:09PM -0300, Jason Gunthorpe wrote:
> On Tue, May 10, 2022 at 05:12:04PM +1000, David Gibson wrote:
> > On Mon, May 09, 2022 at 11:00:41AM -0300, Jason Gunthorpe wrote:
> > > On Mon, May 09, 2022 at 04:01:52PM +1000, David Gibson wrote:
> > >
> > > > > The default
> From: Baolu Lu
> Sent: Wednesday, May 11, 2022 10:32 AM
>
> On 2022/5/10 22:02, Jason Gunthorpe wrote:
> > On Tue, May 10, 2022 at 02:17:29PM +0800, Lu Baolu wrote:
> >
> >> This adds a pair of common domain ops for this purpose and adds
> helpers
> >> to attach/detach a domain to/from a
> From: Steve Wahl
> Sent: Wednesday, May 11, 2022 3:07 AM
>
> On Tue, May 10, 2022 at 01:16:26AM +, Tian, Kevin wrote:
> > > From: Steve Wahl
> > > Sent: Friday, May 6, 2022 11:26 PM
> > >
> > > On Fri, May 06, 2022 at 08:12:11AM +, Tian, Kevin wrote:
> > > > > From: David Woodhouse
>
> From: Jason Gunthorpe
> Sent: Wednesday, May 11, 2022 3:00 AM
>
> On Tue, May 10, 2022 at 05:12:04PM +1000, David Gibson wrote:
> > Ok... here's a revised version of my proposal which I think addresses
> > your concerns and simplfies things.
> >
> > - No new operations, but IOAS_MAP gets some
> From: Jason Gunthorpe
> Sent: Monday, May 9, 2022 10:01 PM
>
> On Mon, May 09, 2022 at 04:01:52PM +1000, David Gibson wrote:
>
> > Which is why I'm suggesting that the base address be an optional
> > request. DPDK *will* care about the size of the range, so it just
> > requests that and gets
On 2022/5/10 22:02, Jason Gunthorpe wrote:
On Tue, May 10, 2022 at 02:17:29PM +0800, Lu Baolu wrote:
This adds a pair of common domain ops for this purpose and adds helpers
to attach/detach a domain to/from a {device, PASID}.
I wonder if this should not have a detach op - after discussing
On 2022/5/10 22:34, Jason Gunthorpe wrote:
On Tue, May 10, 2022 at 02:17:28PM +0800, Lu Baolu wrote:
int iommu_device_register(struct iommu_device *iommu,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 627a3ed5ee8f..afc63fce6107
Hi James,
On 2022/5/10 18:14, James Clark wrote:
On 07/04/2022 13:58, Yicong Yang wrote:
From: Qi Liu
[...]
struct auxtrace_record
*auxtrace_record__init(struct evlist *evlist, int *err)
{
@@ -57,8 +112,12 @@ struct auxtrace_record
struct evsel *evsel;
bool
> From: Joao Martins
> Sent: Tuesday, May 10, 2022 7:51 PM
>
> On 5/10/22 02:38, Tian, Kevin wrote:
> >> From: Jason Gunthorpe
> >> Sent: Friday, May 6, 2022 7:46 PM
> >>
> >> On Fri, May 06, 2022 at 03:51:40AM +, Tian, Kevin wrote:
> From: Jason Gunthorpe
> Sent: Thursday, May
> From: Jason Gunthorpe
> Sent: Tuesday, May 10, 2022 9:47 PM
>
> On Tue, May 10, 2022 at 01:38:26AM +, Tian, Kevin wrote:
>
> > > However, tt costs nothing to have dirty tracking as long as all iommus
> > > support it in the system - which seems to be the normal case today.
> > >
> > > We
Hi Jason,
On Tue, 10 May 2022 20:28:04 -0300, Jason Gunthorpe wrote:
> On Tue, May 10, 2022 at 02:07:02PM -0700, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
> > Some modern devices such
Hi Jason,
On Tue, 10 May 2022 20:21:21 -0300, Jason Gunthorpe wrote:
> On Tue, May 10, 2022 at 02:07:01PM -0700, Jacob Pan wrote:
> > +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> > + struct device *dev,
> > +
On Tue, May 10, 2022 at 02:07:02PM -0700, Jacob Pan wrote:
> DMA mapping API is the de facto standard for in-kernel DMA. It operates
> on a per device/RID basis which is not PASID-aware.
>
> Some modern devices such as Intel Data Streaming Accelerator, PASID is
> required for certain work
On Tue, May 10, 2022 at 02:07:01PM -0700, Jacob Pan wrote:
> +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> + struct device *dev,
> + ioasid_t pasid)
> +{
> + struct device_domain_info *info =
The current in-kernel supervisor PASID support is based on the SVM/SVA
machinery in SVA lib. The binding between a kernel PASID and kernel
mapping has many flaws. See discussions in the link below.
This patch enables in-kernel DMA by switching from SVA lib to the
standard DMA mapping APIs. Since
DMA mapping API is the de facto standard for in-kernel DMA. It operates
on a per device/RID basis which is not PASID-aware.
Some modern devices such as Intel Data Streaming Accelerator, PASID is
required for certain work submissions. To allow such devices use DMA
mapping API, we need the
Supervisor PASID for SVA/SVM is no longer supported, delete the unused
flag.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 2 +-
include/linux/intel-svm.h | 13 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/iommu/intel/svm.c
Some modern accelerators such as Intel's Data Streaming Accelerator (DSA)
require PASID in DMA requests to be operational. Specifically, the work
submissions with ENQCMD on shared work queues require PASIDs. The use cases
include both user DMA with shared virtual addressing (SVA) and in-kernel
DMA
On VT-d platforms with scalable mode enabled, devices issue DMA requests
with PASID need to attach PASIDs to given IOMMU domains. The attach
operation involves the following:
- Programming the PASID into the device's PASID table
- Tracking device domain and the PASID relationship
- Managing IOTLB
On Tue, May 10, 2022 at 01:16:26AM +, Tian, Kevin wrote:
> > From: Steve Wahl
> > Sent: Friday, May 6, 2022 11:26 PM
> >
> > On Fri, May 06, 2022 at 08:12:11AM +, Tian, Kevin wrote:
> > > > From: David Woodhouse
> > > > Sent: Friday, May 6, 2022 3:17 PM
> > > >
> > > > On Fri,
On Tue, May 10, 2022 at 05:12:04PM +1000, David Gibson wrote:
> On Mon, May 09, 2022 at 11:00:41AM -0300, Jason Gunthorpe wrote:
> > On Mon, May 09, 2022 at 04:01:52PM +1000, David Gibson wrote:
> >
> > > > The default iommu_domain that the iommu driver creates will be used
> > > > here, it is up
On Tue, May 10, 2022 at 01:55:24PM -0300, Jason Gunthorpe wrote:
> This control causes the ARM SMMU drivers to choose a stage 2
> implementation for the IO pagetable (vs the stage 1 usual default),
> however this choice has no visible impact to the VFIO user. Further qemu
> never implemented this
From: Robin Murphy Sent: Tuesday, May 10, 2022 9:34 AM
>
> On 2022-05-10 15:21, Tianyu Lan wrote:
> > From: Tianyu Lan
> >
> > swiotlb_find_slots() skips slots according to io tlb aligned mask
> > calculated from min aligned mask and original physical address
> > offset. This affects max
On Tue, May 10, 2022 at 06:52:06PM +0100, Robin Murphy wrote:
> On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
> > This control causes the ARM SMMU drivers to choose a stage 2
> > implementation for the IO pagetable (vs the stage 1 usual default),
> > however this choice has no visible
On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
This control causes the ARM SMMU drivers to choose a stage 2
implementation for the IO pagetable (vs the stage 1 usual default),
however this choice has no visible impact to the VFIO user. Further qemu
never implemented this and no other
We observed the error "cacheline tracking ENOMEM, dma-debug disabled"
during a light system load (copying some files). The reason for this error
is that the dma_active_cacheline radix tree uses GFP_NOWAIT allocation -
so it can't access the emergency memory reserves and it fails as soon as
anybody
This control causes the ARM SMMU drivers to choose a stage 2
implementation for the IO pagetable (vs the stage 1 usual default),
however this choice has no visible impact to the VFIO user. Further qemu
never implemented this and no other userspace user is known.
The original description in commit
On 2022-05-10 15:21, Tianyu Lan wrote:
From: Tianyu Lan
swiotlb_find_slots() skips slots according to io tlb aligned mask
calculated from min aligned mask and original physical address
offset. This affects max mapping size. The mapping size can't
achieve the IO_TLB_SEGSIZE * IO_TLB_SIZE when
Hi Joerg,
Please pull these Arm SMMU updates for 5.19. The bulk of it is just adding
new device-tree compatible strings for the existing drivers, but there
are some non-critical fixes in here as well. Please see the tag for more
details.
I used the previous fixes pull as a base for this so that
From: Ashish Mhetre
[ Upstream commit 4a25f2ea0e030b2fc852c4059a50181bfc5b2f57 ]
Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
entries to not be invalidated correctly. The problem is that the walk
cache index generated for IOVA is not same across translation and
From: Ashish Mhetre
[ Upstream commit 4a25f2ea0e030b2fc852c4059a50181bfc5b2f57 ]
Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
entries to not be invalidated correctly. The problem is that the walk
cache index generated for IOVA is not same across translation and
On Tue, May 10, 2022 at 02:17:34PM +0800, Lu Baolu wrote:
> +/**
> + * iommu_sva_bind_device() - Bind a process address space to a device
> + * @dev: the device
> + * @mm: the mm to bind, caller must hold a reference to mm_users
> + * @drvdata: opaque data pointer to pass to bind callback
> + *
>
On Tue, May 10, 2022 at 02:17:31PM +0800, Lu Baolu wrote:
> The current kernel DMA with PASID support is based on the SVA with a flag
> SVM_FLAG_SUPERVISOR_MODE. The IOMMU driver binds the kernel memory address
> space to a PASID of the device. The device driver programs the device with
> kernel
On Tue, May 10, 2022 at 02:17:28PM +0800, Lu Baolu wrote:
> int iommu_device_register(struct iommu_device *iommu,
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 627a3ed5ee8f..afc63fce6107 100644
> +++
From: Tianyu Lan
swiotlb_find_slots() skips slots according to io tlb aligned mask
calculated from min aligned mask and original physical address
offset. This affects max mapping size. The mapping size can't
achieve the IO_TLB_SEGSIZE * IO_TLB_SIZE when original offset is
non-zero. This will
On Tue, May 10, 2022 at 02:17:29PM +0800, Lu Baolu wrote:
> This adds a pair of common domain ops for this purpose and adds helpers
> to attach/detach a domain to/from a {device, PASID}.
I wonder if this should not have a detach op - after discussing with
Robin we can see that detach_dev is not
On 10/05/2022 12:18, Yicong Yang wrote:
> On 2022/5/10 17:46, James Clark wrote:
>>
>>
>> On 07/04/2022 13:58, Yicong Yang wrote:
>>> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
>>> Endpoint(RCiEP) device, providing the capability to dynamically monitor and
>>>
On 07/04/2022 13:58, Yicong Yang wrote:
> From: Qi Liu
>
> 'perf record' and 'perf report --dump-raw-trace' supported in this
> patch.
>
> Example usage:
>
> Output will contain raw PTT data and its textual representation, such
> as:
>
> 0 0 0x5810 [0x30]: PERF_RECORD_AUXTRACE size:
On 07/04/2022 13:58, Yicong Yang wrote:
> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
> Endpoint(RCiEP) device, providing the capability to dynamically monitor and
> tune the PCIe traffic, and trace the TLP headers.
>
> Add the driver for the device to enable
On Tue, May 10, 2022 at 01:38:26AM +, Tian, Kevin wrote:
> > However, tt costs nothing to have dirty tracking as long as all iommus
> > support it in the system - which seems to be the normal case today.
> >
> > We should just always turn it on at this point.
>
> Then still need a way to
On 2022/5/10 20:54, James Clark wrote:
>
>
> On 10/05/2022 12:18, Yicong Yang wrote:
>> On 2022/5/10 17:46, James Clark wrote:
>>>
>>>
>>> On 07/04/2022 13:58, Yicong Yang wrote:
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
Endpoint(RCiEP) device,
On 2022/5/10 19:23, Will Deacon wrote:
> On Thu, Apr 07, 2022 at 08:58:35PM +0800, Yicong Yang wrote:
>> The DMA operations of HiSilicon PTT device can only work properly with
>> identical mappings. So add a quirk for the device to force the domain
>> as passthrough.
>>
>> Signed-off-by: Yicong
Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
> The HPET-based hardlockup detector relies on the TSC to determine if an
> observed NMI interrupt was originated by HPET timer. Hence, this detector
> can no longer be used with an unstable TSC.
>
> In such case, permanently stop the
On 5/10/22 02:38, Tian, Kevin wrote:
>> From: Jason Gunthorpe
>> Sent: Friday, May 6, 2022 7:46 PM
>>
>> On Fri, May 06, 2022 at 03:51:40AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, May 5, 2022 10:08 PM
On Thu, May 05, 2022 at 07:40:37AM +, Tian,
On Tue, May 10 2022 at 21:16, Nicholas Piggin wrote:
> Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
>> +/*
>> + * If in use, the HPET hardlockup detector relies on tsc_khz.
>> + * Reconfigure it to make use of the refined tsc_khz.
>> + */
>> +
On Tue, 10 May 2022 09:38:58 +0100, Robin Murphy wrote:
> When using the legacy "mmu-masters" DT binding, we reject DMA domains
> since we have no guarantee of driver probe order and thus can't rely on
> client drivers getting the correct DMA ops. However, we can do better
> than fall back to the
On Thu, Apr 07, 2022 at 08:58:35PM +0800, Yicong Yang wrote:
> The DMA operations of HiSilicon PTT device can only work properly with
> identical mappings. So add a quirk for the device to force the domain
> as passthrough.
>
> Signed-off-by: Yicong Yang
> ---
>
On 2022/5/10 17:46, James Clark wrote:
>
>
> On 07/04/2022 13:58, Yicong Yang wrote:
>> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
>> Endpoint(RCiEP) device, providing the capability to dynamically monitor and
>> tune the PCIe traffic, and trace the TLP headers.
Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
> The HPET hardlockup detector relies on tsc_khz to estimate the value of
> that the TSC will have when its HPET channel fires. A refined tsc_khz
> helps to estimate better the expected TSC value.
>
> Using the early value of tsc_khz
Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
> Prepare hardlockup_panic_setup() to handle a comma-separated list of
> options. Thus, it can continue parsing its own command-line options while
> ignoring parameters that are relevant only to specific implementations of
> the
Excerpts from Ricardo Neri's message of May 6, 2022 9:59 am:
> Certain implementations of the hardlockup detector require support for
> Inter-Processor Interrupt shorthands. On x86, support for these can only
> be determined after all the possible CPUs have booted once (in
> smp_init()). Other
When using the legacy "mmu-masters" DT binding, we reject DMA domains
since we have no guarantee of driver probe order and thus can't rely on
client drivers getting the correct DMA ops. However, we can do better
than fall back to the old no-default-domain behaviour now, by forcing an
identity
On 2022-05-10 08:23, Shameerali Kolothum Thodi wrote:
Hi Joerg/Robin,
I think this series is now ready to be merged. Could you please let
me know if there is anything missing.
Fine by me - these patches have had enough review and testing now that
even if anything else did come up, I think it
Hi Joerg/Robin,
I think this series is now ready to be merged. Could you please let
me know if there is anything missing.
Thanks,
Shameer
> -Original Message-
> From: Guohanjun (Hanjun Guo)
> Sent: 05 May 2022 02:24
> To: Shameerali Kolothum Thodi ;
>
On Mon, May 09, 2022 at 11:00:41AM -0300, Jason Gunthorpe wrote:
> On Mon, May 09, 2022 at 04:01:52PM +1000, David Gibson wrote:
>
> > > The default iommu_domain that the iommu driver creates will be used
> > > here, it is up to the iommu driver to choose something reasonable for
> > > use by
Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code
for SVA implementation in iommu core.
Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
---
drivers/iommu/{iommu-sva-lib.h => iommu-sva.h} | 0
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +-
Tweak the I/O page fault handling framework to route the page faults to
the domain and call the page fault handler retrieved from the domain.
This makes the I/O page fault handling framework possible to serve more
usage scenarios as long as they have an IOMMU domain and install a page
fault
This adds some mechanisms around the iommu_domain so that the I/O page
fault handling framework could route a page fault to the domain and
call the fault handler from it.
Add pointers to the page fault handler and its private data in struct
iommu_domain. The fault handler will be called with the
These ops'es have been replaced with the dev_attach/detach_pasid domain
ops'es. There's no need for them anymore. Remove them to avoid dead
code.
Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
---
include/linux/intel-iommu.h | 4 --
include/linux/iommu.h
The existing iommu SVA interfaces are implemented by calling the SVA
specific iommu ops provided by the IOMMU drivers. There's no need for
any SVA specific ops in iommu_ops vector anymore as we can achieve
this through the generic attach/detach_dev_pasid domain ops.
This refactors the IOMMU SVA
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 6 ++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 68 +++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +
3
The current kernel DMA with PASID support is based on the SVA with a flag
SVM_FLAG_SUPERVISOR_MODE. The IOMMU driver binds the kernel memory address
space to a PASID of the device. The device driver programs the device with
kernel virtual address (KVA) for DMA access. There have been security and
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 5
drivers/iommu/intel/iommu.c | 2 ++
drivers/iommu/intel/svm.c | 48 +
3 files changed, 55 insertions(+)
Use below data structures for SVA implementation in the IOMMU core:
- struct iommu_domain (IOMMU_DOMAIN_SVA type)
Represent a hardware pagetable that the IOMMU hardware could use for
SVA translation. Multiple iommu domains could be bound with an SVA mm
and each grabs a mm_count of the mm in
From: Dave Jiang
The idxd driver always gated the pasid enabling under a single knob and
this assumption is incorrect. The pasid used for kernel operation can be
independently toggled and has no dependency on the user pasid (and vice
versa). Split the two so they are independent "enabled" flags.
Use this field to save the pasid/ssid bits that a device is able to
support with its IOMMU hardware. It is a generic attribute of a device
and lifting it into the per-device dev_iommu struct makes it possible
to allocate a PASID for device without calls into the IOMMU drivers.
Any iommu driver
Attaching an IOMMU domain to a PASID of a device is a generic operation
for modern IOMMU drivers which support PASID-granular DMA address
translation. Currently visible usage scenarios include (but not limited):
- SVA (Shared Virtual Address)
- kernel DMA with PASID
- hardware-assist mediated
Hi folks,
The former part of this series refactors the IOMMU SVA code by assigning
an SVA type of iommu_domain to a shared virtual address and replacing
sva_bind/unbind iommu ops with attach/detach_dev_pasid domain ops.
The latter part changes the existing I/O page fault handling framework
from
68 matches
Mail list logo
