Hi linux-block and iommu mailing lists,
I have an issue that a USB SSD with xHCI on R-Car H3 causes "swiotlb is full"
like below.
[ 36.745286] xhci-hcd ee00.usb: swiotlb buffer is full (sz: 524288
bytes), total 32768 (slots), used 1338 (slots)
I have investigated this issue by using
Introduce a new type for reserved region. This corresponds
to directly mapped regions which are known to be relaxable
in some specific conditions, such as device assignment use
case. Well known examples are those used by USB controllers
providing PS/2 keyboard emulation for pre-boot BIOS and
early
In the case the RMRR device scope is a PCI-PCI bridge, let's check
the device belongs to the PCI sub-hierarchy.
Fixes: 0659b8dc45a6 ("iommu/vt-d: Implement reserved region get/put callbacks")
Signed-off-by: Eric Auger
Reviewed-by: Lu Baolu
---
v5 -> v6:
- Added Lu's R-b
---
intel_iommu_get_resv_regions() aims to return the list of
reserved regions accessible by a given @device. However several
devices can access the same reserved memory region and when
building the list it is not safe to use a single iommu_resv_region
object, whose container is the RMRR. This
In case we expand an existing region, we unlink
this latter and insert the larger one. In
that case we should free the original region after
the insertion. Also we can immediately return.
Fixes: 6c65fb318e8b ("iommu: iommu_get_group_resv_regions")
Signed-off-by: Eric Auger
---
Stop providing our own arch alloc/free hooks and just expose the segment
offset and use the generic dma-direct allocator.
Signed-off-by: Christoph Hellwig
---
arch/nios2/Kconfig| 1 +
arch/nios2/include/asm/page.h | 6 --
arch/nios2/mm/dma-mapping.c | 34
Stop providing our own arch alloc/free hooks for nommu platforms and
just expose the segment offset and use the generic dma-direct
allocator.
Signed-off-by: Christoph Hellwig
---
arch/microblaze/Kconfig | 2 +
arch/microblaze/mm/consistent.c | 97 +++--
2
Hi all,
can you take a look at this series? It switches niops2 and microblaze to
use the generic dma layer support for uncached segements.
The dma mapping for-next git tree that includes the support is available
here:
git://git.infradead.org/users/hch/dma-mapping.git for-next
Gitweb:
When reading the vtd specification and especially the
Reserved Memory Region Reporting Structure chapter,
it is not obvious a device scope element cannot be a
PCI-PCI bridge, in which case all downstream ports are
likely to access the reserved memory region. Let's handle
this case in
Currently the Intel reserved region is attached to the
RMRR unit and when building the list of RMRR seen by a device
we link this unique reserved region without taking care of
potential multiple usage of this reserved region by several devices.
Also while reading the vtd spec it is unclear to me
Several call sites are about to check whether a device belongs
to the PCI sub-hierarchy of a candidate PCI-PCI bridge.
Introduce an helper to perform that check.
Signed-off-by: Eric Auger
Reviewed-by: Lu Baolu
---
v5 -> v6:
- fix kerneldoc comment as suggested by Christoph
- added Lu's R-b
Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory
region type, let's report USB and GFX RMRRs as relaxable ones.
We introduce a new device_rmrr_is_relaxable() helper to check
whether the rmrr belongs to the relaxable category.
This allows to have a finer reporting at IOMMU API level
On Wed, May 01, 2019 at 05:13:57PM +, Paul Burton wrote:
> Hi Christoph,
>
> On Wed, May 01, 2019 at 03:13:39PM +0200, Christoph Hellwig wrote:
> > Stop providing our arch alloc/free hooks and just expose the segment
> > offset instead.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> >
FYI, I've merged this patch into the dma-mapping tree to make progress
with the generic uncached segment support for mips.
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
>
> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> >
> > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> > >
> > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
> > > >
> > > > This solves a problem we see with drm/msm, caused by
On Fri, May 31, 2019 at 04:16:02PM -0400, Qian Cai wrote:
> The commit "iommu/vt-d: Delegate the dma domain to upper layer" left an
> unused variable,
>
> drivers/iommu/intel-iommu.c: In function 'disable_dmar_iommu':
> drivers/iommu/intel-iommu.c:1652:23: warning: variable 'domain' set but
> not
On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
>
> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> >
> > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > >
> > > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> > > >
> > > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
> > >
On Thu, 30 May 2019, Zhen Lei wrote:
> The default DMA mode is LAZY on s390, this patch make it can be set to
> STRICT at build time. It can be overridden by boot option.
>
> There is no functional change.
>
> Signed-off-by: Zhen Lei
Acked-by: Sebastian Ott
From: Robin Murphy
Apparently, some Qualcomm arm64 platforms which appear to expose their
SMMU global register space are still, in fact, using a hypervisor to
mediate it by trapping and emulating register accesses. Sadly, some
deployed versions of said trapping code have bugs wherein they go
On Mon, Jun 3, 2019 at 11:52 AM Joerg Roedel wrote:
>
> Hi Tom,
>
> On Mon, May 06, 2019 at 07:52:02PM +0100, Tom Murphy wrote:
> > Convert the AMD iommu driver to the dma-iommu api. Remove the iova
> > handling and reserve region code from the AMD iommu driver.
>
> Thank you for your work on
On Mon, May 27, 2019 at 01:52:47PM +0200, Geert Uytterhoeven wrote:
> Geert Uytterhoeven (6):
> iommu/ipmmu-vmsa: Link IOMMUs and devices in sysfs
> iommu/ipmmu-vmsa: Prepare to handle 40-bit error addresses
> iommu/ipmmu-vmsa: Make IPMMU_CTX_MAX unsigned
> iommu/ipmmu-vmsa: Move num_utlbs
On 6/3/2019 11:50 AM, Tomasz Figa wrote:
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
This solves a problem we see with drm/msm,
On Wed, May 29, 2019 at 01:15:32AM -0700, Nathan Chancellor wrote:
> Fixes: 06d60728ff5c ("iommu/dma: move the arm64 wrappers to common code")
> Link: https://github.com/ClangBuiltLinux/linux/issues/497
> Signed-off-by: Nathan Chancellor
> ---
> drivers/iommu/dma-iommu.c | 2 +-
> 1 file
Hi Tom,
On Mon, May 06, 2019 at 07:52:02PM +0100, Tom Murphy wrote:
> Convert the AMD iommu driver to the dma-iommu api. Remove the iova
> handling and reserve region code from the AMD iommu driver.
Thank you for your work on this! I appreciate that much, but I am not
sure we are ready to make
If you (and a few others actors in the thread) want people to actually
read what you wrote please follow proper mailing list ettiquette. I've
given up on reading all the recent mails after scrolling through two
pages of full quotes.
___
iommu mailing
On Mon, Jun 3, 2019 at 12:57 AM Vivek Gautam
wrote:
>
>
>
> On 6/3/2019 11:50 AM, Tomasz Figa wrote:
> > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> >> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> >>> On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> On Sat, Dec 1, 2018 at
On Mon, Jun 3, 2019 at 4:14 PM Rob Clark wrote:
>
> On Mon, Jun 3, 2019 at 12:57 AM Vivek Gautam
> wrote:
> >
> >
> >
> > On 6/3/2019 11:50 AM, Tomasz Figa wrote:
> > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > >> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > >>> On Tue, Dec
On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
> >
> > On 03/06/2019 11:47, Rob Clark wrote:
> > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> > >>
> > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > >>>
> > >>>
On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding wrote:
>
> On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
> > >
> > > On 03/06/2019 11:47, Rob Clark wrote:
> > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> > > >>
> > >
On Mon, 2019-06-03 at 14:07 +0100, Robin Murphy wrote:
> On 03/06/2019 13:59, Qian Cai wrote:
> > There are a few macros in IOMMU have single-char identifiers make the
> > code hard to read and debug. Replace them with meaningful names.
> >
> > Suggested-by: Andrew Morton
> > Signed-off-by: Qian
On Mon, Jun 03, 2019 at 12:14:27PM +0100, Robin Murphy wrote:
> On 03/06/2019 11:47, Rob Clark wrote:
> > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> > >
> > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > > >
> > > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > > > >
I want to pull in the cache maintainance fix for the dma-iommu
conversion. Hope it didn't cause any inconvenience.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> It shouldn't be a problem to hook something else up to the IOMMU
> subsystem. Hopefully it's something that people are going to standardize
> on.
>
> > 3) The automatic attach of DMA domain is also causing a different
> >problem for us on the GPU side, preventing us from supporting per-
> >
From: Jacob Pan
Traditionally, device specific faults are detected and handled within
their own device drivers. When IOMMU is enabled, faults such as DMA
related transactions are detected by IOMMU. There is no generic
reporting mechanism to report faults back to the in-kernel device
driver or
Some IOMMU hardware features, for example PCI PRI and Arm SMMU Stall,
enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page
Requests and Stall events through the new fault reporting API. The
consumer of the fault can be either an I/O page fault handler in the host,
or a guest
From: Jacob Pan
DMA faults can be detected by IOMMU at device level. Adding a pointer
to struct device allows IOMMU subsystem to report relevant faults
back to the device driver for further handling.
For direct assigned device (or user space drivers), guest OS holds
responsibility to handle and
Allow device drivers and VFIO to get notified on IOMMU translation
fault, and handle recoverable faults (PCI PRI). Several series require
this API (Intel VT-d and Arm SMMUv3 nested support, as well as the
generic host SVA implementation).
Changes since v1 [1]:
* Allocate iommu_param earlier, in
From: Jacob Pan
Device faults detected by IOMMU can be reported outside the IOMMU
subsystem for further processing. This patch introduces
a generic device fault data structure.
The fault can be either an unrecoverable fault or a page request,
also referred to as a recoverable fault.
We only
The commit "iommu/vt-d: Probe DMA-capable ACPI name space devices"
introduced a compilation warning due to the "iommu" variable in
for_each_active_iommu() but never used the for each element, i.e,
"drhd->iommu".
drivers/iommu/intel-iommu.c: In function 'probe_acpi_namespace_devices':
On Mon, Jun 03, 2019 at 07:20:14AM -0700, Rob Clark wrote:
> On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding
> wrote:
> >
> > On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> > > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
> > > >
> > > > On 03/06/2019 11:47, Rob Clark wrote:
>
On 03/06/2019 14:29, Qian Cai wrote:
On Mon, 2019-06-03 at 14:07 +0100, Robin Murphy wrote:
On 03/06/2019 13:59, Qian Cai wrote:
There are a few macros in IOMMU have single-char identifiers make the
code hard to read and debug. Replace them with meaningful names.
Suggested-by: Andrew Morton
On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
>
> On 03/06/2019 11:47, Rob Clark wrote:
> > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> >>
> >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> >>>
> >>> So, another case I've come across, on the display side.. I'm working
> >>> on
Hi Maxime, Joerg,
On Wed, 22 May 2019 at 21:27, Rob Herring wrote:
>
> On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote:
> >
> > Hi,
> >
> > The Allwinner H6 has a Mali-T720 MP2 which should be supported by
> > the new panfrost driver. This series fix two issues and introduce the
> >
Am 31.05.19 um 19:32 schrieb Laurentiu Tudor:
>> -Original Message-
>> From: Andreas Färber
>> Sent: Friday, May 31, 2019 8:04 PM
>>
>> Hello Laurentiu,
>>
>> Am 31.05.19 um 18:46 schrieb Laurentiu Tudor:
-Original Message-
From: Andreas Färber
Sent: Friday, May
On Sun, 26 May 2019 18:09:57 +0200
Eric Auger wrote:
> From: "Liu, Yi L"
>
> This patch adds VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE ioctl
> which aims to pass/withdraw the virtual iommu guest configuration
> to/from the VFIO driver downto to the iommu subsystem.
>
> Signed-off-by: Jacob Pan
>
On Sun, 26 May 2019 18:09:39 +0200
Eric Auger wrote:
> From: Jean-Philippe Brucker
>
> Some IOMMU hardware features, for example PCI's PRI and Arm SMMU's Stall,
> enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page
> Requests and Stall events through the new fault
On Sun, 26 May 2019 18:10:00 +0200
Eric Auger wrote:
> This patch adds two new regions aiming to handle nested mode
> translation faults.
>
> The first region (two host kernel pages) is read-only from the
> user-space perspective. The first page contains an header
> that provides information
On Sun, 26 May 2019 18:09:40 +0200
Eric Auger wrote:
> From: Jacob Pan
>
> When an IO page request is processed outside IOMMU subsystem, response
> can be delayed or lost. Add a tunable setup parameter such that user can
> choose the timeout for IOMMU to track pending page requests.
>
> This
On Sun, 26 May 2019 18:10:01 +0200
Eric Auger wrote:
> This patch registers a fault handler which records faults in
> a circular buffer and then signals an eventfd. This buffer is
> exposed within the fault region.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v3 -> v4:
> - move
On Sun, 26 May 2019 18:10:03 +0200
Eric Auger wrote:
> Add a new VFIO_PCI_DMA_FAULT_IRQ_INDEX index. This allows to
> set/unset an eventfd that will be triggered when DMA translation
> faults are detected at physical level when the nested mode is used.
>
> Signed-off-by: Eric Auger
> ---
>
This patch replaces dma_{alloc,release}_from_contiguous() with
dma_{alloc,free}_contiguous() to simplify those function calls.
Signed-off-by: Nicolin Chen
---
drivers/iommu/dma-iommu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
On Mon, 3 Jun 2019 15:57:47 +0100
Jean-Philippe Brucker wrote:
> +/**
> + * struct iommu_fault_page_request - Page Request data
> + * @flags: encodes whether the corresponding fields are valid and
> whether this
> + * is the last page in group (IOMMU_FAULT_PAGE_REQUEST_*
> values)
> + *
On 29/04/2019 13:56, Robin Murphy wrote:
> On 22/04/2019 18:59, Christoph Hellwig wrote:
>> There is nothing really arm64 specific in the iommu_dma_ops
>> implementation, so move it to dma-iommu.c and keep a lot of symbols
>> self-contained. Note the implementation does depend on the
>>
On Mon, 3 Jun 2019 15:57:45 +0100
Jean-Philippe Brucker wrote:
> Allow device drivers and VFIO to get notified on IOMMU translation
> fault, and handle recoverable faults (PCI PRI). Several series require
> this API (Intel VT-d and Arm SMMUv3 nested support, as well as the
> generic host SVA
Michael S. Tsirkin writes:
> On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
>> I rephrased it in terms of address translation. What do you think of
>> this version? The flag name is slightly different too:
>>
>>
>> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature
On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote:
>
>
> Michael S. Tsirkin writes:
>
> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
> >> I rephrased it in terms of address translation. What do you think of
> >> this version? The flag name is
56 matches
Mail list logo
