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
---
drivers/iommu/int
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 device_has_rmr
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 o
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
---
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:
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 fil
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 w
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 iommu_re
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
---
drivers/iommu/iom
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 +++--
FYI, I've merged this patch into the dma-mapping tree to make progress
with the generic uncached segment support for mips.
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
> > ---
> > a
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
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 gettin
In order to making it ready for calling iommu_bounce_map() and
iommu_bounce_unmap() in __intel_map_single() and intel_unmap(),
we need to do some code refactoring.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Mika Westerberg
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.
The Intel VT-d hardware uses paging for DMA remapping.
The minimum mapped window is a page size. The device
drivers may map buffers not filling the whole IOMMU
window. This allows the device to access to possibly
unrelated memory and a malicious device could exploit
this to perform DMA attacks. To
This adds a helper to check whether a device needs to
use bounce buffer. It also provides a boot time option
to disable the bounce buffer. Users can use this to
prevent the iommu driver from using the bounce buffer
for performance gain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by:
The Thunderbolt vulnerabilities are public and have a nice
name as Thunderclap [1] [3] nowadays. This patch series aims
to mitigate those concerns.
An external PCI device is a PCI peripheral device connected
to the system through an external bus, such as Thunderbolt.
What makes it different is tha
IOMMU hardware always use paging for DMA remapping. The
minimum mapped window is a page size. The device drivers
may map buffers not filling whole IOMMU window. It allows
device to access to possibly unrelated memory and various
malicious devices can exploit this to perform DMA attack.
This intro
This splits the size parameter to swiotlb_tbl_map_single() and
swiotlb_tbl_unmap_single() into an alloc_size and a mapping_size
parameter, where the latter one is rounded up to the iommu page
size.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
---
drivers/xen/swiotlb-xen.c | 8 --
This is necessary to avoid exposing valid kernel data to any
milicious device.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
---
kernel/dma/swiotlb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index f956f785645a..ed41eb7f6131
The direct dma implementation depends on swiotlb. Hence, don't
switch of swiotlb since direct dma interfaces are used in this
driver.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Mika Westerberg
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 6 --
1 file changed, 6 deletions
This adds trace support for the Intel IOMMU driver. It
also declares some events which could be used to trace
the events when an IOVA is being mapped or unmapped in
a domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Mika Westerberg
Signed-off-by: Lu Baolu
---
drivers/iommu/M
There are several places in the kernel where it is necessary to
check whether a device is a pci untrusted device. Add a helper
to simplify the callers.
Signed-off-by: Lu Baolu
---
include/linux/pci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
Hi,
On 5/29/19 2:16 PM, Christoph Hellwig wrote:
On Sat, May 25, 2019 at 01:41:31PM +0800, Lu Baolu wrote:
Some platforms may support ACPI name-space enumerated devices
that are capable of generating DMA requests. Platforms which
support DMA remapping explicitly declares any such DMA-capable
AC
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 getting
> > > iommu_dma_ops while we attach our own domain and manage i
27 matches
Mail list logo
