On 2020/7/7 9:39, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:
- Create a group for mdev with iommu_group_alloc();
- Add the device to the group with
grou
Firmware that traps writes to S2CR to translate BYPASS into FAULT also
ignores writes of type FAULT. As such booting with "disable_bypass" set
will result in all S2CR registers left as configured by the bootloader.
This has been seen to result in indeterministic results, as these
mappings might li
Expose the SMR and S2CR structs in the header file, to allow platform
specific implementations to populate/initialize the smrs and s2cr
arrays.
Signed-off-by: Bjorn Andersson
---
drivers/iommu/arm-smmu.c | 14 --
drivers/iommu/arm-smmu.h | 15 +++
2 files changed, 15 inse
Turn all stream mappings marked as valid into BYPASS. This allows the
platform specific implementation to configure stream mappings to match
the boot loader's configuration for e.g. display to continue to function
through the reset of the SMMU.
Suggested-by: Robin Murphy
Signed-off-by: Bjorn Ande
Some firmware found on various Qualcomm platforms traps writes to S2CR
of type BYPASS and writes FAULT into the register. This prevents us from
marking the streams for the display controller as BYPASS to allow
continued scanout of the screen through the initialization of the ARM
SMMU.
This adds a
Based on previous attempts and discussions this is the latest attempt at
inheriting stream mappings set up by the bootloader, for e.g. boot splash or
efifb.
The first patch is an implementation of Robin's suggestion that we should just
mark the relevant stream mappings as BYPASS. Relying on someth
With many Qualcomm platforms not having functional S2CR BYPASS a
temporary IOMMU domain, without translation, needs to be allocated in
order to allow these memory transactions.
Unfortunately the boot loader uses the first few context banks, so
rather than overwriting a active bank the last context
On Fri 03 Jul 05:31 PDT 2020, Will Deacon wrote:
> On Tue, Jun 09, 2020 at 03:40:18PM -0400, Jonathan Marek wrote:
> > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> >
> > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > few changes. Notably, the H
On Tue 09 Jun 12:40 PDT 2020, Jonathan Marek wrote:
> Use the qcom implementation for IOMMU hardware on sm8150 and sm8250 SoCs.
>
> Signed-off-by: Jonathan Marek
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/iommu/arm-smmu-impl.c | 4 +++-
> 1 file changed, 3 insertions(+), 1
Hi Kevin,
> From: Tian, Kevin
> Sent: Thursday, July 9, 2020 10:18 AM
>
> > From: Liu, Yi L
> > Sent: Thursday, July 9, 2020 10:08 AM
> >
> > Hi Kevin,
> >
> > > From: Tian, Kevin
> > > Sent: Thursday, July 9, 2020 9:57 AM
> > >
> > > > From: Liu, Yi L
> > > > Sent: Thursday, July 9, 2020 8:3
> From: Liu, Yi L
> Sent: Thursday, July 9, 2020 10:08 AM
>
> Hi Kevin,
>
> > From: Tian, Kevin
> > Sent: Thursday, July 9, 2020 9:57 AM
> >
> > > From: Liu, Yi L
> > > Sent: Thursday, July 9, 2020 8:32 AM
> > >
> > > Hi Alex,
> > >
> > > > Alex Williamson
> > > > Sent: Thursday, July 9, 2020
Hi Kevin,
> From: Tian, Kevin
> Sent: Thursday, July 9, 2020 9:57 AM
>
> > From: Liu, Yi L
> > Sent: Thursday, July 9, 2020 8:32 AM
> >
> > Hi Alex,
> >
> > > Alex Williamson
> > > Sent: Thursday, July 9, 2020 3:55 AM
> > >
> > > On Wed, 8 Jul 2020 08:16:16 +
> > > "Liu, Yi L" wrote:
> >
> From: Liu, Yi L
> Sent: Thursday, July 9, 2020 8:32 AM
>
> Hi Alex,
>
> > Alex Williamson
> > Sent: Thursday, July 9, 2020 3:55 AM
> >
> > On Wed, 8 Jul 2020 08:16:16 +
> > "Liu, Yi L" wrote:
> >
> > > Hi Alex,
> > >
> > > > From: Liu, Yi L < yi.l@intel.com>
> > > > Sent: Friday, Jul
> Subject: [kbuild-all] Re: [PATCH v4 4/7] iommu/vt-d: Handle non-page aligned
> address
>
> Hi Jacob,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on iommu/next]
> [also build test WARNING on linux/master linus/master v5.8-rc4 next-20200707]
> [If your
Hi Jacob,
On 7/8/20 11:29 PM, Jacob Pan wrote:
On Wed, 8 Jul 2020 10:07:13 +0800
Lu Baolu wrote:
Hi,
On 7/8/20 7:43 AM, Jacob Pan wrote:
+For UAPIs that are shared with in-kernel users, a wrapper function
+is provided to distinguish the callers. For example,
+
+Userspace caller ::
+
+ int
Hi Alex,
On 7/9/20 3:07 AM, Alex Williamson wrote:
On Wed, 8 Jul 2020 10:53:12 +0800
Lu Baolu wrote:
Hi Alex,
Thanks a lot for your comments. Please check my reply inline.
On 7/8/20 5:04 AM, Alex Williamson wrote:
On Tue, 7 Jul 2020 09:39:56 +0800
Lu Baolu wrote:
The hardware assist
Hi Kevin,
On 7/6/20 9:47 AM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, July 6, 2020 8:26 AM
After a page request is handled, software must response the device which
raised the page request with the handling result. This is done through
'response' is a noun.
Yes.
the iommu ops.page
Hi Alex,
> Alex Williamson
> Sent: Thursday, July 9, 2020 3:55 AM
>
> On Wed, 8 Jul 2020 08:16:16 +
> "Liu, Yi L" wrote:
>
> > Hi Alex,
> >
> > > From: Liu, Yi L < yi.l@intel.com>
> > > Sent: Friday, July 3, 2020 2:28 PM
> > >
> > > Hi Alex,
> > >
> > > > From: Alex Williamson
> > > >
Hi Alex,
> From: Alex Williamson
> Sent: Thursday, July 9, 2020 3:30 AM
>
> On Wed, 8 Jul 2020 08:08:40 +
> "Liu, Yi L" wrote:
>
> > Hi Alex,
> >
> > Eric asked if we will to have data strcut other than struct
> > iommu_nesting_info
> > type in the struct vfio_iommu_type1_info_cap_nesting
Hi,
On 7/7/20 7:28 AM, Nicolas Saenz Julienne wrote:
When allocating atomic DMA memory for a device, the dma-pool core
queries __dma_direct_optimal_gfp_mask() to check which atomic pool to
use. It turns out the GFP flag returned is only an optimistic guess.
The pool selected might sometimes live
Hi,
On 7/8/20 11:49 AM, Nicolas Saenz Julienne wrote:
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. So stop using it.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map
On Wed, 24 Jun 2020 11:24:51 +0100, Robin Murphy wrote:
> The comment about implementation and integration quirks being
> mutually-exclusive is out of date, and in fact the code is already
> structured for the case it anticipates, so document that properly.
Applied to will (for-joerg/arm-smmu/upda
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
On Tue, Jul 07, 2020 at 10:00:14PM -0700, Krishna Reddy wrote:
> ioremap smmu mmio region before calling into implementation init.
> This is necessary to allow mapped address available during vendor
> specific implementation init.
>
> Signed-off-by: Krishna Reddy
Reviewed-by: Nicolin Chen
_
On Tue, Jul 07, 2020 at 10:00:15PM -0700, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC has three ARM MMU-500 instances.
> It uses two of the ARM MMU-500s together to interleave IOVA
> accesses across them and must be programmed identically.
> This implementation supports programming the two ARM MMU
On Tue, Jul 07, 2020 at 10:00:13PM -0700, Krishna Reddy wrote:
> Move TLB timeout and spin count macros to header file to
> allow using the same from vendor specific implementations.
>
> Signed-off-by: Krishna Reddy
Reviewed-by: Nicolin Chen
___
iommu
On Tue, Jul 07, 2020 at 10:00:17PM -0700, Krishna Reddy wrote:
> Add global/context fault hooks to allow vendor specific implementations
> override default fault interrupt handlers.
>
> Update NVIDIA implementation to override the default global/context fault
> interrupt handlers and handle interr
On Wed, 8 Jul 2020 08:16:16 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Liu, Yi L < yi.l@intel.com>
> > Sent: Friday, July 3, 2020 2:28 PM
> >
> > Hi Alex,
> >
> > > From: Alex Williamson
> > > Sent: Friday, July 3, 2020 5:19 AM
> > >
> > > On Wed, 24 Jun 2020 01:55:19 -0700
> > > L
On Tue, Jul 07, 2020 at 12:36:42PM +0100, Robin Murphy wrote:
> On 2020-06-26 21:04, Jordan Crouse wrote:
> >Add support to create a io-pgtable for use by targets that support
> >per-instance pagetables. In order to support per-instance pagetables the
> >GPU SMMU device needs to have the qcom,adre
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
allowing multiple offsets. See the 'v1' notes below for more info.
v7:
Commit: "device core: Introduce DMA range map, supplanting .
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
On Wed, 8 Jul 2020 08:08:40 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> Eric asked if we will to have data strcut other than struct iommu_nesting_info
> type in the struct vfio_iommu_type1_info_cap_nesting @info[] field. I'm not
> quit sure on it. I guess the answer may be not as VFIO's nesting supp
On Tue, Jul 07, 2020 at 07:58:18AM -0700, Rob Clark wrote:
> On Tue, Jul 7, 2020 at 7:25 AM Rob Clark wrote:
> >
> > On Tue, Jul 7, 2020 at 4:34 AM Robin Murphy wrote:
> > >
> > > On 2020-06-26 21:04, Jordan Crouse wrote:
> > > > Allow a io-pgtable implementation to skip TLB operations by checkin
On Wed, 8 Jul 2020 10:53:12 +0800
Lu Baolu wrote:
> Hi Alex,
>
> Thanks a lot for your comments. Please check my reply inline.
>
> On 7/8/20 5:04 AM, Alex Williamson wrote:
> > On Tue, 7 Jul 2020 09:39:56 +0800
> > Lu Baolu wrote:
> >
> >> The hardware assistant vfio mediated device is a u
On Wed, Jul 08, 2020 at 06:49:39PM +0200, Nicolas Saenz Julienne wrote:
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. So stop using it.
>
> Fixes: c84dc6e68a1d ("dma-pool: add addition
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. So stop using it.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp
mask")
Reported-by: Jeremy Linton
Signed-off-by:
On 2020-07-08 16:36, Christoph Hellwig wrote:
On Wed, Jul 08, 2020 at 12:35:34PM +0200, Nicolas Saenz Julienne wrote:
Which allows me to switch between ACPI/DT on the machine. In DT mode it
works fine now,
Nice, would that count as a Tested-by from you?
but with ACPI I continue to have failu
On Wed, Jul 08, 2020 at 06:00:35PM +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-07-08 at 17:35 +0200, Christoph Hellwig wrote:
> > On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote:
> > > When allocating atomic DMA memory for a device, the dma-pool core
> > > queries __d
On Wed, 2020-07-08 at 17:35 +0200, Christoph Hellwig wrote:
> On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote:
> > When allocating atomic DMA memory for a device, the dma-pool core
> > queries __dma_direct_optimal_gfp_mask() to check which atomic pool to
> > use. It turns out
Use the DMA API bypass mechanism for direct window mappings. This uses
common code and speed up the direct mapping case by avoiding indirect
calls just when not using dma ops at all. It also fixes a problem where
the sync_* methods were using the bypass check for DMA allocations, but
those are pa
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Signed-off-by: Christoph Hellwig
---
include/linux/device.h | 8 +
On Wed, Jul 08, 2020 at 12:35:34PM +0200, Nicolas Saenz Julienne wrote:
> > Which allows me to switch between ACPI/DT on the machine. In DT mode it
> > works fine now,
>
> Nice, would that count as a Tested-by from you?
>
> > but with ACPI I continue to have failures unless I
> > disable CMA v
Avoid the overhead of the dma ops support for tiny builds that only
use the direct mapping.
Signed-off-by: Christoph Hellwig
---
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig| 1 +
arch/ia64/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/parisc/Kconfig
On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote:
> When allocating atomic DMA memory for a device, the dma-pool core
> queries __dma_direct_optimal_gfp_mask() to check which atomic pool to
> use. It turns out the GFP flag returned is only an optimistic guess.
> The pool selec
Inline the single page map/unmap/sync dma-direct calls into the now
out of line generic wrappers. This restores the behavior of a single
function call that we had before moving the generic calls out of line.
Besides the dma-mapping callers there are just a few callers in IOMMU
drivers that have a
For a long time the DMA API has been implemented inline in dma-mapping.h,
but the function bodies can be quite large. Move them all out of line.
This also removes all the dma_direct_* exports as those are just
implementation details and should never be used by drivers directly.
Signed-off-by: Ch
Hi all,
I've recently beeing chatting with Lu about using dma-iommu and
per-device DMA ops in the intel IOMMU driver, and one missing feature
in dma-iommu is a bypass mode where the direct mapping is used even
when an iommu is attached to improve performance. The powerpc
code already has a simila
On Wed, 8 Jul 2020 10:07:13 +0800
Lu Baolu wrote:
> Hi,
>
> On 7/8/20 7:43 AM, Jacob Pan wrote:
> > +For UAPIs that are shared with in-kernel users, a wrapper function
> > +is provided to distinguish the callers. For example,
> > +
> > +Userspace caller ::
> > +
> > + int iommu_sva_unbind_gpasi
Hi Alex,
All points below are taken. I have sent out v4 that addresses these
feedbacks. Thanks for the review.
Jacob
On Tue, 7 Jul 2020 15:40:54 -0600
Alex Williamson wrote:
> On Mon, 29 Jun 2020 16:05:18 -0700
> Jacob Pan wrote:
>
> > On Fri, 26 Jun 2020 16:19:23 -0600
> > Alex Williamson
On Wed, 8 Jul 2020 10:17:57 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 7/8/20 7:43 AM, Jacob Pan wrote:
> > IOMMU UAPI data size is filled by the user space which must be
> > validated by ther kernel. To ensure backward compatibility, user
> > data can only be extended by either re-purpose padding
Hi,
On 7/8/20 5:35 AM, Nicolas Saenz Julienne wrote:
Hi Jim,
On Tue, 2020-07-07 at 17:08 -0500, Jeremy Linton wrote:
Hi,
I spun this up on my 8G model using the PFTF firmware from:
https://github.com/pftf/RPi4/releases
Which allows me to switch between ACPI/DT on the machine. In DT mode it
On 2020-07-08 07:50, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 04:41:16PM +0100, Robin Murphy wrote:
On 2020-06-28 18:16, Bj�rn T�pel wrote:
On 2020-06-27 09:04, Christoph Hellwig wrote:
On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote:
Given there is roughly a ~5 w
On 22/06/2020 18:28, John Garry wrote:
Hi, Can you guys let me know if this is on the radar at all?
I have been talking about this performance issue since Jan, and not
getting anything really.
thanks
As mentioned in [0], the CPU may consume many cycles processing
arm_smmu_cmdq_issue_cmdlist
On 08/07/2020 06:00, Krishna Reddy wrote:
> Add global/context fault hooks to allow vendor specific implementations
> override default fault interrupt handlers.
>
> Update NVIDIA implementation to override the default global/context fault
> interrupt handlers and handle interrupts across the two
On 08/07/2020 06:00, Krishna Reddy wrote:
> Add binding for NVIDIA's Tegra194 SoC SMMU.
>
> Signed-off-by: Krishna Reddy
> ---
> .../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/
Looks pretty sensible.
> - if (!dmar_forcedac && dma_mask > DMA_BIT_MASK(32)) {
> + if (!dmar_forcedac && dma_mask > DMA_BIT_MASK(32) &&
> + dev_is_pci(dev) && !pci_is_pcie(to_pci_dev(dev))) {
The only thing I wonder is if it is worth to add a little helper
for this check, but wit
On 08/07/2020 06:00, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC has three ARM MMU-500 instances.
> It uses two of the ARM MMU-500s together to interleave IOVA
> accesses across them and must be programmed identically.
> This implementation supports programming the two ARM MMU-500s
> that must b
On Wed, Jul 08, 2020 at 07:57:23AM +, Song Bao Hua (Barry Song) wrote:
> > int dma_map_batch_start(struct device *dev, size_t rounded_len,
> > enum dma_data_direction dir, unsigned long attrs, dma_addr_t *addr);
> > int dma_map_batch_add(struct device *dev, dma_addr_t *addr, struct page
> >
On 08/07/2020 06:00, Krishna Reddy wrote:
> ioremap smmu mmio region before calling into implementation init.
> This is necessary to allow mapped address available during vendor
> specific implementation init.
>
> Signed-off-by: Krishna Reddy
> ---
> drivers/iommu/arm-smmu.c | 8
> 1
On 08/07/2020 06:00, Krishna Reddy wrote:
> Move TLB timeout and spin count macros to header file to
> allow using the same from vendor specific implementations.
>
> Signed-off-by: Krishna Reddy
> ---
> drivers/iommu/arm-smmu.c | 3 ---
> drivers/iommu/arm-smmu.h | 2 ++
> 2 files changed, 2 i
For devices stuck behind a conventional PCI bus, saving extra cycles at
33MHz is probably fairly significant. However since native PCI Express
is now the norm for high-performance devices, the optimisation to always
prefer 32-bit addresses for the sake of avoiding DAC is starting to look
rather ana
As for the intel-iommu implementation, relegate the opportunistic
attempt to allocate a SAC address to the domain of conventional PCI
devices only, to avoid it increasingly causing far more performance
issues than possible benefits on modern PCI Express systems.
Signed-off-by: Robin Murphy
---
d
Hi Matthias and Yingjoe,
Thanks for your comments!
On Mon, 2020-07-06 at 17:17 +0200, Matthias Brugger wrote:
>
> On 04/07/2020 03:16, Yingjoe Chen wrote:
> > On Fri, 2020-07-03 at 12:41 +0800, Chao Hao wrote:
> >> Given the fact that we are adding more and more plat_data bool values,
> >> it wou
Hi Jim,
On Tue, 2020-07-07 at 17:08 -0500, Jeremy Linton wrote:
> Hi,
>
> I spun this up on my 8G model using the PFTF firmware from:
>
> https://github.com/pftf/RPi4/releases
>
> Which allows me to switch between ACPI/DT on the machine. In DT mode it
> works fine now,
Nice, would that count
On 7/8/20 9:44 AM, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 03:39:01PM +0200, Björn Töpel wrote:
On 2020-06-29 15:03, Christoph Hellwig wrote:
Hi all,
this series lifts the somewhat hacky checks in the XSK code if a DMA
streaming mapping needs dma_sync_single_for_{device,cpu} calls to
Le 06/07/2020 à 10:26, Jonathan Cameron a écrit :
> On Sun, 5 Jul 2020 09:53:58 +
> "Song Bao Hua (Barry Song)" wrote:
>
>>> -Original Message-
>>> From: Will Deacon [mailto:w...@kernel.org]
>>> Sent: Saturday, July 4, 2020 4:22 AM
>>> To: Song Bao Hua (Barry Song)
>>> Cc: robin.mur.
Hi,
I spun this up on my 8G model using the PFTF firmware from:
https://github.com/pftf/RPi4/releases
Which allows me to switch between ACPI/DT on the machine. In DT mode it
works fine now, but with ACPI I continue to have failures unless I
disable CMA via cma=0 on the kernel command line. It
Hi Alex,
> From: Liu, Yi L < yi.l@intel.com>
> Sent: Friday, July 3, 2020 2:28 PM
>
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Friday, July 3, 2020 5:19 AM
> >
> > On Wed, 24 Jun 2020 01:55:19 -0700
> > Liu Yi L wrote:
> >
> > > This patch allows user space to request PASID allocatio
Hi Alex,
Eric asked if we will to have data strcut other than struct iommu_nesting_info
type in the struct vfio_iommu_type1_info_cap_nesting @info[] field. I'm not
quit sure on it. I guess the answer may be not as VFIO's nesting support should
based on IOMMU UAPI. how about your opinion?
+#define
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Christoph Hellwig
> Sent: Wednesday, July 8, 2020 6:50 PM
> To: Robin Murphy
> Cc: Björn Töpel ; Christoph Hellwig ;
> Daniel Borkmann ; maxi...@mellanox.com;
> konrad.w...@ora
On Mon, Jun 29, 2020 at 03:39:01PM +0200, Björn Töpel wrote:
> On 2020-06-29 15:03, Christoph Hellwig wrote:
>> Hi all,
>>
>> this series lifts the somewhat hacky checks in the XSK code if a DMA
>> streaming mapping needs dma_sync_single_for_{device,cpu} calls to the
>> DMA API.
>>
>
> Thanks a lot
71 matches
Mail list logo