One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct qcom_iommu_dev {
...
struct qcom_iommu_ctx *ctxs[0]; /*
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Hi Xen maintainers and friends,
>
> please take a look at this series that cleans up the parts of swiotlb-xen
> that deal with non-coherent caches.
>
> Changes since v1:
> - rewrite dma_cache_maint to be much simpler
> - improve various comments
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Now that the Xen special cases are gone nothing worth mentioning is
> left in the arm64 file, so switch to use the
> asm-generic version instead.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Will Deacon
Reviewed-by: Stefano Stabellini
>
On Tue, 27 Aug 2019, Christoph Hellwig wrote:
> And this was still buggy I think, it really needs some real Xen/Arm
> testing which I can't do. Hopefully better version below:
>
> --
> >From 5ad4b6e291dbb49f65480c9b769414931cbd485a Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Wed,
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> The only thing left of page-coherent.h is two functions implemented by
> the architecture for non-coherent DMA support that are never called for
> fully coherent architectures. Just move the prototypes for those to
> swiotlb-xen.h instead.
>
>
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> No need for a no-op wrapper.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> drivers/xen/swiotlb-xen.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git
Add global/context fault hooks to allow Nvidia SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 127
drivers/iommu/arm-smmu.c| 6 ++
drivers/iommu/arm-smmu.h|
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Now that we know we always have the dma-noncoherent.h helpers available
> if we are on an architecture with support for non-coherent devices,
> we can just call them directly, and remove the calls to the dma-direct
> routines, including the fact that
Add Memory controller DT node on T194 and enable it.
This patch is a prerequisite for SMMU enable on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 4
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 7 +++
2 files changed, 11 insertions(+)
Enable SMMU translations for SDHCI and EQOS transactions.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index ad509bb..0496a87
Add Nvidia SMMUv2 implementation and model info.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 2 +
drivers/iommu/arm-smmu-nvidia.c | 97 +
Add binding doc for Nvidia's smmu-v2 implementation.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+ Boris, Juergen
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> x86 currently calls alloc_pages, but using dma-direct works as well
> there, with the added benefit of using the CMA pool if available.
> The biggest advantage is of course to remove a pointless bit of
> architecture specific code.
Hi All,
Nvidia Arm SMMUv2 implementation has two ARM SMMU(MMU-500) instances
that are used together for SMMU translations. The IOVA accesses from
HW devices are interleaved across these two SMMU instances and need
to be programmed identical except during tlb sync and fault handling.
This patch
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> xen_dma_map_page uses a different and more complicated check for foreign
> pages than the other three cache maintainance helpers. Switch it to the
> simpler pfn_valid method a well, and document the scheme with a single
> improved comment in
tlb_sync hook allows nvidia smmu handle tlb sync
across multiple SMMUs as necessary.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 32
drivers/iommu/arm-smmu.c| 8 +---
drivers/iommu/arm-smmu.h| 4
3 files changed,
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 75
1 file changed, 75 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Calculate the required operation in the caller, and pass it directly
> instead of recalculating it for each page, and use simple arithmetics
> to get from the physical address to Xen page size aligned chunks.
>
> Signed-off-by: Christoph Hellwig
>
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
> grown variant. Note that both are always initialized to the same
> value in arch_setup_dma_ops.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Julien Grall
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
> non-coherent devices.
This patch does a bunch of things not listed in the commit message, such
as moving the static inline functions to include/xen/arm/page-coherent.h
and
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> These routines are only used by swiotlb-xen, which cannot be modular.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/xen/mm.c | 2 --
> arch/x86/xen/mmu_pv.c | 2 --
> 2 files changed, 4 deletions(-)
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
> need for a pointer indirection.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/mm/dma-mapping.c| 3
On Thu, Aug 29, 2019 at 04:58:22PM +0300, Dmitry Osipenko wrote:
> 29.08.2019 15:40, Thierry Reding пишет:
> > On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
> >> On 8/26/19 3:31 PM, YueHaibing wrote:
> >>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> >>> to m
I've applied this to the dma-mapping for-next tree now.
If there are any issues with the parisc patch I'll happily take
incremental patches.
I've pulled this into the dma-mapping for-next tree now.
On Tue, Jul 30, 2019 at 04:50:45PM +0300, Laurent Pinchart wrote:
> I would have indented this line to match the rest. Apart from that,
I've fixed that up now that I've applied the patch.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Wed, Aug 28, 2019 at 09:01:06AM -0600, Keith Busch wrote:
> On Wed, Aug 28, 2019 at 07:14:42AM -0700, Christoph Hellwig wrote:
> > With a little tweak to the intel-iommu code we should be able to work
> > around the VMD mess for the requester IDs without having to create giant
> > amounts of
On Wed, Aug 28, 2019 at 04:41:45PM +, Derrick, Jonathan wrote:
> > diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> > index 6fa846920f5f..75fe28492290 100644
> > --- a/arch/x86/include/asm/pci.h
> > +++ b/arch/x86/include/asm/pci.h
> > @@ -35,12 +35,15 @@ extern int
29.08.2019 15:40, Thierry Reding пишет:
> On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
>> On 8/26/19 3:31 PM, YueHaibing wrote:
>>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
>>> to m will set IOMMU_IOVA to m, this fails the building of
>>> TEGRA_HOST1X and
On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
> On 8/26/19 3:31 PM, YueHaibing wrote:
> > If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> > to m will set IOMMU_IOVA to m, this fails the building of
> > TEGRA_HOST1X and DRM_TEGRA which is y like this:
> >
> >
On Wed, Aug 28, 2019 at 9:23 PM Masahiro Yamada
wrote:
>
> On Wed, Aug 28, 2019 at 7:53 PM Masahiro Yamada
> wrote:
> >
> > Hi Christoph,
> >
> > On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig wrote:
> > >
> > > On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > > > Yes,
On 8/26/19 3:31 PM, YueHaibing wrote:
> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> to m will set IOMMU_IOVA to m, this fails the building of
> TEGRA_HOST1X and DRM_TEGRA which is y like this:
>
> drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
>
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Jean-Philippe Brucker
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Thierry Reding
---
drivers/iommu/virtio-iommu.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Thierry Reding
---
drivers/iommu/arm-smmu-v3.c | 11 +--
drivers/iommu/arm-smmu.c| 11 +--
2 files changed, 2 insertions(+), 20 deletions(-)
From: Thierry Reding
Use the new standard function instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/iommu/amd_iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index
From: Thierry Reding
Implement a generic function for removing reserved regions. This can be
used by drivers that don't do anything fancy with these regions other
than allocating memory for them.
Signed-off-by: Thierry Reding
---
drivers/iommu/iommu.c | 19 +++
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: David Woodhouse
Signed-off-by: Thierry Reding
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
From: Thierry Reding
Most IOMMU drivers only need to free the memory allocated for each
reserved region. Instead of open-coding the loop to do this in each
driver, extract the code into a common function that can be used by
all these drivers.
Thierry
Thierry Reding (5):
iommu: Implement
From: Thierry Reding
For device tree nodes, use the standard of_iommu_get_resv_regions()
implementation to obtain the reserved memory regions associated with a
device.
Cc: Rob Herring
Cc: Frank Rowand
Cc: devicet...@vger.kernel.org
Signed-off-by: Thierry Reding
---
drivers/iommu/dma-iommu.c
From: Thierry Reding
These two patches implement support for retrieving a list of reserved
regions for a device from its device tree node. These regions are
described by the reserved-memory bindings:
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
These reserved
From: Thierry Reding
This is an implementation that IOMMU drivers can use to obtain reserved
memory regions from a device tree node. It uses the reserved-memory DT
bindings to find the regions associated with a given device. These
regions will be used to create 1:1 mappings in the IOMMU domain
Hi,
On 8/29/19 3:58 PM, Janusz Krzysztofik wrote:
Hi Baolu,
On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
Hi Janusz,
On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
We should avoid kernel panic when a intel_unmap() is called against
a non-existent domain.
Does that mean you
Hi Baolu,
On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
> >> We should avoid kernel panic when a intel_unmap() is called against
> >> a non-existent domain.
> > Does that mean you suggest to replace
> >
43 matches
Mail list logo
