DMA allocations with the DMA_ATTR_NO_KERNEL_MAPPING do not return a kernel
virtual address for use in driver, but are expected to be used entirely
for userspace mappings and/or device private memory.
Because of that we don't need to remap them as uncached, and thus don't need
the atomic pool for n
Thanks,
applied to dma-mapping for-next.
Can you also send a conversion of drivers/iommu/dma-iommu.c to your
new helpers against this tree?
http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/for-next
On Mon, May 27, 2019 at 05:38:29PM +0200, Christoph Hellwig wrote:
> On Mon, May 27, 2019 at 05:37:51PM +0200, Joerg Roedel wrote:
> > I applied this series to a new generic-dma-ops branch in the iommu
> > tree and plan to send it upstream in the next merge window.
>
> Thanks! Can you push the br
On Mon, May 27, 2019 at 05:37:51PM +0200, Joerg Roedel wrote:
> I applied this series to a new generic-dma-ops branch in the iommu
> tree and plan to send it upstream in the next merge window.
Thanks! Can you push the branch out ASAP, as I'll need to pull it
into the dma-mapping tree to avoid cre
Hi Christoph, Hi Robin,
On Mon, May 20, 2019 at 09:29:24AM +0200, Christoph Hellwig wrote:
> I think we are finally ready for the generic dma-iommu series. I have
> various DMA API changes pending, and Tom has patches ready to convert
> the AMD and Intel iommu drivers over to it. I'd love to hav
On Mon, May 27, 2019 at 10:55:36AM +0200, Eric Auger wrote:
> - list_add_tail(&rmrr->resv->list, head);
> + length = rmrr->end_address - rmrr->base_address + 1;
> + resv = iommu_alloc_resv_region(rmrr->base_address,
> +
On Mon, May 27, 2019 at 11:26:04AM +0200, Joerg Roedel wrote:
> On Sun, May 12, 2019 at 12:31:59PM -0400, Michael S. Tsirkin wrote:
> > OK this has been in next for a while.
> >
> > Last time IOMMU maintainers objected. Are objections
> > still in force?
> >
> > If not could we get acks please?
>
Hey James, Lu Baolu,
On Sat, May 25, 2019 at 01:41:21PM +0800, Lu Baolu wrote:
> James Sewart (1):
> iommu/vt-d: Implement apply_resv_region iommu ops entry
>
> Lu Baolu (14):
> iommu: Add API to request DMA domain for device
> iommu/vt-d: Expose ISA direct mapping region via
> iommu_ge
On Tue, May 21, 2019 at 03:30:15PM +0800, Lu Baolu wrote:
> ---
> drivers/iommu/intel-iommu.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Applied both, thanks.
On Tue, May 21, 2019 at 03:27:35PM +0800, Lu Baolu wrote:
> The iommu_group_get_for_dev() will allocate a group for a
> device if it isn't in any group. This isn't the use case
> in iommu_request_dm_for_dev(). Let's use iommu_group_get()
> instead.
>
> Fixes: d290f1e70d85a ("iommu: Introduce iommu
Hi Zhen Lei,
On Mon, May 20, 2019 at 09:59:47PM +0800, Zhen Lei wrote:
> arch/ia64/kernel/pci-dma.c| 2 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
> arch/s390/pci/pci_dma.c | 2 +-
> arch/x86/kernel/pci-dma.c | 7 ++---
> drivers/
On Fri, May 24, 2019 at 04:40:14PM -0700, Sai Praneeth Prakhya wrote:
> Changes from V2 to V3:
> --
> Presently, for V2 patches if kernel command line argument "iommu=pt" is
> passed,
> dumping DMAR table seg faults. This happens because in pass through mode (for
> non-scalable
On Fri, May 24, 2019 at 02:30:56PM +0800, Lu Baolu wrote:
> So that all types are printed in the same format.
>
> Fixes: c52c72d3dee81 ("iommu: Add sysfs attribyte for domain type")
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
A
On Mon, May 20, 2019 at 03:41:28PM +0200, Lukasz Odzioba wrote:
> We use RCU's for rarely updated lists like iommus, rmrr, atsr units.
>
> I'm not sure why domain_remove_dev_info() in domain_exit() was surrounded
> by rcu_read_lock. Lock was present before refactoring in d160aca527,
> but it was r
Hi Kevin,
On Thu, May 16, 2019 at 05:52:40PM -0700, Kevin Mitchell wrote:
> Signed-off-by: Kevin Mitchell
somehow I didn't receive the cover letter and patch 3 of this set, can
you please re-send so I have it all for review?
Regards,
Joerg
On R-Car Gen3, the faulting virtual address is a 40-bit address, and
comprised of two registers. Read the upper address part, and combine
both parts, when running on a 64-bit system.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
Reviewed-by: Yoshihiro Shimoda
Tested-by: Yoshihiro
ipmmu_domain_init_context() takes care of (1) initializing the software
domain, and (2) initializing the hardware context for the domain.
Extract the code to initialize the hardware context into a new subroutine
ipmmu_domain_setup_context(), to prepare for later reuse.
Signed-off-by: Geert Uytter
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and all
IPMMU state is lost. Hence after s2ram, devices wired behind an IPMMU,
and configured to use it, will see their DMA operations hang.
To fix this, restore all IPMMU contexts, and re-enable all active
micro-TLBs during system res
Make the IPMMU_CTX_MAX constant unsigned, to match the type of
ipmmu_features.number_of_contexts.
This allows to use plain min() instead of type-casting min_t().
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Reviewed-by: Simon Horman
Reviewed-by: Yoshihiro Shimoda
Tested-by:
As of commit 7af9a5fdb9e0ca33 ("iommu/ipmmu-vmsa: Use
iommu_device_sysfs_add()/remove()"), IOMMU devices show up under
/sys/class/iommu/, but their "devices" subdirectories are empty.
Likewise, devices tied to an IOMMU do not have an "iommu" backlink.
Make sure all links are created, on both arm32
Hi Jörg, Magnus,
On R-Car Gen3 systems with PSCI, PSCI may power down the SoC during
system suspend, thus losing all IOMMU state. Hence after s2ram, devices
behind an IPMMU (e.g. SATA), and configured to use it, will fail to
complete their I/O operations.
This patch series adds suspend/r
The maximum number of micro-TLBs per IPMMU instance is not fixed, but
depends on the SoC type. Hence move it from struct ipmmu_vmsa_device to
struct ipmmu_features, and set up the correct value for both R-Car Gen2
and Gen3 SoCs.
Note that currently no code uses this value.
Signed-off-by: Geert U
Hi Ira,
On Fri, May 24, 2019 at 09:16:19AM -0700, Ira Weiny wrote:
> On Thu, May 23, 2019 at 09:06:33PM -0700, Nicolin Chen wrote:
> > The addresses within a single page are always contiguous, so it's
> > not so necessary to always allocate one single page from CMA area.
> > Since the CMA area has
On Sat, May 11, 2019 at 01:41:35PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable npages is being initialized however this is never read and
> later it is being reassigned to a new value. The initialization is
> redundant and hence can be removed.
>
> Addresses-Coverity: ("Unus
On Wed, May 08, 2019 at 12:22:46PM -0700, Jacob Pan wrote:
> If multiple devices try to bind to the same mm/PASID, we need to
> set up first level PASID entries for all the devices. The current
> code does not consider this case which results in failed DMA for
> devices after the first bind.
>
> S
On Sun, May 12, 2019 at 12:31:59PM -0400, Michael S. Tsirkin wrote:
> OK this has been in next for a while.
>
> Last time IOMMU maintainers objected. Are objections
> still in force?
>
> If not could we get acks please?
No objections against the code, I only hesitated because the Spec was
not ye
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
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
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
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
---
drivers/iommu/intel-iommu.c | 37 +
1 file changed, 29 insertions(+)
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
---
drivers/iommu/intel-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 d
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
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
We plan to call iommu_alloc_resv_region in a non preemptible section.
Pass a GFP flag to the function and update all the call sites.
Signed-off-by: Eric Auger
---
drivers/acpi/arm64/iort.c | 3 ++-
drivers/iommu/amd_iommu.c | 7 ---
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-s
35 matches
Mail list logo
