This adds two new aux-domain APIs for a use case like vfio/mdev where
sub-devices derived from an aux-domain capable device are created and
put in an iommu_group.
/**
* iommu_aux_attach_group - attach an aux-domain to an iommu_group which
* contains sub-devices (for
On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 09/07/2020 01:24, Christoph Hellwig wrote:
> > 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
Hi Prabhakar,
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Lad Prabhakar
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> +++
On 14/07/2020 17:07, Christoph Hellwig wrote:
> On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/07/2020 01:24, Christoph Hellwig wrote:
>>> Several IOMMU drivers have a bypass mode where they can use a direct
>>> mapping if the devices DMA mask is large
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> Renesas RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible
> DMA controllers, therefore document RZ/G2H specific bindings.
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
This series aims to extend the IOMMU aux-domain API set so that it
could be more friendly to vfio/mdev usage. The interactions between
vfio/mdev and iommu during mdev creation and passthr are:
1. Create a group for mdev with iommu_group_alloc();
2. Add the device to the group with
group =
The device driver needs an API to get its aux-domain. A typical usage
scenario is:
unsigned long pasid;
struct iommu_domain *domain;
struct device *dev = mdev_dev(mdev);
struct device *iommu_device = vfio_mdev_get_iommu_device(dev);
domain =
Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
vfio_group data structure so that it could be reused in other places.
Signed-off-by: Lu Baolu
---
drivers/vfio/vfio_iommu_type1.c | 44
The iommu aux-domain api's work only when IOMMU_DEV_FEAT_AUX is enabled
for the device. Add this check to avoid misuse.
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/iommu.c
On Mon, Jul 13, 2020 at 01:48:29PM -0700, John Stultz wrote:
> On Mon, Jul 13, 2020 at 1:41 PM Will Deacon wrote:
> > On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
> > > On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
> > > > On Thu, Jul 09, 2020 at 08:28:45PM -0700, John
Hi Prabhakar,
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Thanks for your patch!
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++
Hello!
On 14.07.2020 0:35, Lad Prabhakar wrote:
From: Marian-Cristian Rotariu
Document RZ/G2H (R8A774E1) SoC bindings.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
Reviewed-by: Sergei Shtylyov
[...]
MBR, Sergei
___
Hi Tomasz,
On Thu, Jul 02, 2020 at 10:16:29PM +0200, Tomasz Nowicki wrote:
> There were already two versions of series to support SMMU for AP806,
> including workaround for accessing ARM SMMU 64bit registers.
> First [1] by Hanna Hawa and second [2] by Gregory CLEMENT.
> Since it got stuck this
On Fri, Jun 12, 2020 at 11:39:55AM +0800, Baolin Wang wrote:
> Now the ARM page tables are always allocated by GFP_ATOMIC parameter,
> but the iommu_ops->map() function has been added a gfp_t parameter by
> commit 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map"),
> thus
On Mon, 2020-07-13 at 15:03 +0800, Pi-Hsun Shih wrote:
> On Sat, Jul 11, 2020 at 2:51 PM Yong Wu wrote:
> >
> > In the previous SoC, the M4U HW is in the EMI power domain which is
> > always on. the latest M4U is in the display power domain which may be
> > turned on/off, thus we have to add
Hi Will,
> From: Will Deacon
> Sent: Monday, July 13, 2020 9:15 PM
>
> On Sun, Jul 12, 2020 at 04:20:58AM -0700, Liu Yi L wrote:
> > This patch is added as instead of returning a boolean for
> > DOMAIN_ATTR_NESTING,
> > iommu_domain_get_attr() should return an iommu_nesting_info handle.
> >
>
From: Marian-Cristian Rotariu
Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
drivers/iommu/ipmmu-vmsa.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
Hi All,
Patch 1/2 was posted as part of series [1] as pointed out by Geert we need to
have an entry in both the lists soc_rcar_gen3 and soc_rcar_gen3_whitelist to
enable iommu unconditionally, this is now fixed in patch 1/2, also note the DT
binding documentation for R8A774E1 is part of [1].
Add an entry for r8a77961 in soc_rcar_gen3[] list so that we dont
enable iommu unconditionally.
Fixes: 17fe161816398 ("iommu/renesas: Add support for r8a77961")
Signed-off-by: Lad Prabhakar
---
drivers/iommu/ipmmu-vmsa.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Will,
On 14.07.2020 10:19, Will Deacon wrote:
Hi Tomasz,
On Thu, Jul 02, 2020 at 10:16:29PM +0200, Tomasz Nowicki wrote:
There were already two versions of series to support SMMU for AP806,
including workaround for accessing ARM SMMU 64bit registers.
First [1] by Hanna Hawa and second [2]
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
wrote:
> Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
> relevant dt-bindings.
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven --
On Tue, Jul 14, 2020 at 01:57:03PM +0800, Lu Baolu wrote:
> Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
> It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
> vfio_group data structure so that it could be reused in other places.
This removes the last
On Mon, Jul 13, 2020 at 11:36 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
On Fri, Jun 12, 2020 at 11:39:54AM +0800, Baolin Wang wrote:
> Now the __iommu_map() and __iommu_map_sg() are used only in iommu.c
> file, so mark them as static.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/iommu/iommu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
Hi Prabhakar,
On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
wrote:
> On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven
> wrote:
> > On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> > wrote:
> > > From: Marian-Cristian Rotariu
> > >
> > > Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
> > >
On Mon, 2020-07-13 at 15:33 +0800, Pi-Hsun Shih wrote:
> On Sat, Jul 11, 2020 at 2:51 PM Yong Wu wrote:
> >
> > For multiple iommu_domains, we need to reserve some iova regions, so we
> > will add mtk_iommu_iova_region structure. It includes the base address
> > and size of the range.
> > This is
Hi Shimoda-san,
On Tue, Jul 14, 2020 at 1:42 PM Yoshihiro Shimoda
wrote:
> > From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM
> > On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
> > wrote:
> > > On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven
> > > wrote:
> > > > On Mon, Jul
This is my attempt at fixing one of the regressions we've seen[1] after
the introduction of per-zone atomic pools.
This combined with "dma-pool: Do not allocate pool memory from CMA"[2]
should fix the boot issues on Jeremy's RPi4 setup.
[1] https://lkml.org/lkml/2020/7/2/974
[2]
dma_coherent_ok() checks if a physical memory area fits a device's DMA
constraints.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-direct.h
dma-pool's dev_to_pool() creates the false impression that there is a
way to grantee a mapping between a device's DMA constraints and an
atomic pool. It tuns out it's just a guess, and the device might need to
use an atomic pool containing memory from a 'safer' (or lower) memory
zone.
To help
When allocating DMA memory from a pool, the core can only guess which
atomic pool will fit a device's constraints. If it doesn't, get a safer
atomic pool and try again.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp
mask")
Reported-by: Jeremy Linton
Suggested-by:
The function is only used once and can be simplified to a one-liner.
Signed-off-by: Nicolas Saenz Julienne
---
kernel/dma/pool.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 39ca26fa41b5..318035e093fb 100644
---
On Mon, Jul 13, 2020 at 07:45:49PM -0700, Liu, Yi L wrote:
> > From: Fenghua Yu
> > Sent: Tuesday, July 14, 2020 7:48 AM
> >
> > PASID is defined as a few different types in iommu including "int",
> > "u32", and "unsigned int". To be consistent and to match with uapi
> > definitions, define PASID
The name "update_pte" is a little too generic, and can end up clashing
with architecture pagetable code leaked out of common mm headers. Rename
it to something more appropriately namespaced.
Reported-by: kernel test robot
Acked-by: Marek Szyprowski
Signed-off-by: Robin Murphy
---
v2: fix typo
On Mon, Jul 13, 2020 at 8:10 AM Robin Murphy wrote:
>
> On 2020-07-10 21:29, Krishna Reddy wrote:
> > Thanks Rob. One question on setting "minItems: ". Please see below.
> >
> >>> +allOf:
> >>> + - if:
> >>> + properties:
> >>> +compatible:
> >>> + contains:
> >>> +
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM
>
> Hi Prabhakar,
>
> On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
> wrote:
> > On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven
> > wrote:
> > > On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> > > wrote:
>
Hi Geert,
Thank you for the review.
On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven wrote:
>
> Hi Prabhakar,
>
> On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> wrote:
> > From: Marian-Cristian Rotariu
> >
> > Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
> >
> > Signed-off-by:
> From: Yu, Fenghua
> Sent: Tuesday, July 14, 2020 9:55 PM
> On Mon, Jul 13, 2020 at 07:45:49PM -0700, Liu, Yi L wrote:
> > > From: Fenghua Yu
> > > Sent: Tuesday, July 14, 2020 7:48 AM
> > >
> > > PASID is defined as a few different types in iommu including "int",
> > > "u32", and "unsigned
On Tue, 14 Jul 2020 13:57:01 +0800
Lu Baolu wrote:
> This adds two new aux-domain APIs for a use case like vfio/mdev where
> sub-devices derived from an aux-domain capable device are created and
> put in an iommu_group.
>
> /**
> * iommu_aux_attach_group - attach an aux-domain to an
On Tue, 14 Jul 2020 09:25:14 +0100
Christoph Hellwig wrote:
> On Tue, Jul 14, 2020 at 01:57:03PM +0800, Lu Baolu wrote:
> > Replace iommu_aux_at(de)tach_device() with
> > iommu_aux_at(de)tach_group(). It also saves the
> > IOMMU_DEV_FEAT_AUX-capable physcail device in the vfio_group data
> >
From: Colin Ian King
It is possible for the call to omap_iommu_dump_ctx to return
a negative error number, so check for the failure and return
the error number rather than pass the negative value to
simple_read_from_buffer.
Addresses-Coverity: ("Improper use of negative value")
Fixes:
On Mon, 13 Jul 2020 22:00:23 -0700
Jacob Pan wrote:
> Hi Alex,
>
> On Mon, 13 Jul 2020 16:48:42 -0600
> Alex Williamson wrote:
>
> > On Tue, 7 Jul 2020 16:43:45 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support communications between
> > > guest virtual IOMMU
On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
>
> On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat
Hi Joerg,
Replying again because I noticed that I couldn't find this mail in the external
iommu mailing list while I was able to find your comments on my patch. Also,
could you please answer my two questions below?
> -Original Message-
> From: iommu On Behalf Of
> Prakhya, Sai
On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
>
> The ACS "Translation Blocking" bit blocks the translated addresses from
> the devices. We don't expect such traffic from devices unless ATS is
> enabled on them. A device sending such traffic without ATS enabled,
> indicates malicious intent,
The ACS "Translation Blocking" bit blocks the translated addresses from
the devices. We don't expect such traffic from devices unless ATS is
enabled on them. A device sending such traffic without ATS enabled,
indicates malicious intent, and thus should be blocked.
Enable PCI_ACS_TB by default for
Hi Jacob,
On 7/15/20 12:39 AM, Jacob Pan wrote:
On Tue, 14 Jul 2020 13:57:01 +0800
Lu Baolu wrote:
This adds two new aux-domain APIs for a use case like vfio/mdev where
sub-devices derived from an aux-domain capable device are created and
put in an iommu_group.
/**
*
Hi Christoph and Jacob,
On 7/15/20 12:29 AM, Jacob Pan wrote:
On Tue, 14 Jul 2020 09:25:14 +0100
Christoph Hellwig wrote:
On Tue, Jul 14, 2020 at 01:57:03PM +0800, Lu Baolu wrote:
Replace iommu_aux_at(de)tach_device() with
iommu_aux_at(de)tach_group(). It also saves the
On Tue, 14 Jul 2020 13:04:12 -0600
Alex Williamson wrote:
> On Mon, 13 Jul 2020 22:00:23 -0700
> Jacob Pan wrote:
>
> > Hi Alex,
> >
> > On Mon, 13 Jul 2020 16:48:42 -0600
> > Alex Williamson wrote:
> >
> > > On Tue, 7 Jul 2020 16:43:45 -0700
> > > Jacob Pan wrote:
> > >
> > > >
> From: Lu Baolu
> Sent: Wednesday, July 15, 2020 9:00 AM
>
> Hi Christoph and Jacob,
>
> On 7/15/20 12:29 AM, Jacob Pan wrote:
> > On Tue, 14 Jul 2020 09:25:14 +0100
> > Christoph Hellwig wrote:
> >
> >> On Tue, Jul 14, 2020 at 01:57:03PM +0800, Lu Baolu wrote:
> >>> Replace
On Mon, Jul 13, 2020 at 7:40 PM Robin Murphy wrote:
>
> On 2020-07-13 10:12, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory at unexpected times and/or
On Tue, Jul 14, 2020 at 7:01 PM Christoph Hellwig wrote:
>
> On Mon, Jul 13, 2020 at 12:55:43PM +0100, Robin Murphy wrote:
> > On 2020-07-13 10:12, Claire Chang wrote:
> >> The bounced DMA ops provide an implementation of DMA ops that bounce
> >> streaming DMA in and out of a specially allocated
On Mon, Jul 13, 2020 at 12:55:43PM +0100, Robin Murphy wrote:
> On 2020-07-13 10:12, Claire Chang wrote:
>> The bounced DMA ops provide an implementation of DMA ops that bounce
>> streaming DMA in and out of a specially allocated region. Only the
>> operations relevant to streaming DMA are
This one doesn't appear to actually apply on top of Linus' tree plus the
two previous patches.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
The name "update_pte" is a little too generic, and can end up clashing
with architecture pagetable code leaked out of common mm headers. Rename
it to something mroe appropriately namespaced.
Reported-by: kernel test robot
Signed-off-by: Robin Murphy
---
drivers/iommu/exynos-iommu.c | 12
Hi Robin,
On 14.07.2020 13:33, Robin Murphy wrote:
> The name "update_pte" is a little too generic, and can end up clashing
> with architecture pagetable code leaked out of common mm headers. Rename
> it to something mroe appropriately namespaced.
s/mroe/more
> Reported-by: kernel test robot
>
On Tue, 2020-07-14 at 13:22 +0200, Christoph Hellwig wrote:
> This one doesn't appear to actually apply on top of Linus' tree plus the
> two previous patches.
I'll take care of it.
signature.asc
Description: This is a digitally signed message part
On 2020-07-13 14:14, Joerg Roedel wrote:
On Wed, Jul 08, 2020 at 12:32:42PM +0100, Robin Murphy wrote:
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
58 matches
Mail list logo
