Re: [GIT PULL] IOMMU fixes for -rc5

2020-11-20 Thread pr-tracker-bot
The pull request you sent on Fri, 20 Nov 2020 11:50:35 +:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/iommu-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc8299f9f3b9f3b0e1c8c9f719b5deb2a74ab314

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


RE: [PATCH] iommu: Check return of __iommu_attach_device()

2020-11-20 Thread Shameerali Kolothum Thodi



> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 20 November 2020 14:07
> To: Will Deacon ; Shameerali Kolothum Thodi
> 
> Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org;
> Linuxarm 
> Subject: Re: [PATCH] iommu: Check return of __iommu_attach_device()
> 
> On 2020-11-20 11:15, Will Deacon wrote:
> > On Thu, Nov 19, 2020 at 04:58:46PM +, Shameer Kolothum wrote:
> >> Currently iommu_create_device_direct_mappings() is called
> >> without checking the return of __iommu_attach_device(). This
> >> may result in failures in iommu driver if dev attach returns
> >> error.
> >>
> >> Fixes: ce574c27ae27("iommu: Move
> iommu_group_create_direct_mappings() out of iommu_group_add_device()")
> >> Signed-off-by: Shameer Kolothum
> 
> >> ---
> >> Crash log:
> >> [   31.353605] hns3 :7d:00.3: Adding to iommu group 10
> >> [   31.358822] Unable to handle kernel NULL pointer dereference at virtual
> address 0018
> >> [   31.367567] Mem abort info:
> >> [   31.370350]   ESR = 0x9604
> >> [   31.373391]   EC = 0x25: DABT (current EL), IL = 32 bits
> >> [   31.378680]   SET = 0, FnV = 0
> >> [   31.381720]   EA = 0, S1PTW = 0
> >> [   31.384847] Data abort info:
> >> [   31.387716]   ISV = 0, ISS = 0x0004
> >> [   31.391535]   CM = 0, WnR = 0
> >> [   31.394491] [0018] user address but active_mm is
> swapper
> >> [   31.400818] Internal error: Oops: 9604 [#1] PREEMPT SMP
> >> [   31.406365] Modules linked in:
> >> [   31.409409] CPU: 21 PID: 1 Comm: swapper/0 Not tainted
> 5.10.0-rc4-8-gdd5aba9d719-dirty #79
> >> [   31.417980] Hardware name: Huawei TaiShan 200 (Model
> 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B220.01 03/19/2020
> >> [   31.427588] pstate: 00c9 (nzcv daif +PAN +UAO -TCO BTYPE=--)
> >> [   31.433566] pc : arm_smmu_tlb_inv_range+0x178/0x1f0
> >> [   31.438422] lr : arm_smmu_tlb_inv_range+0x5c/0x1f0
> >> [   31.443190] sp : 80001043b4e0
> >> ...
> >> [   31.531175] Call trace:
> >> [   31.533613]  arm_smmu_tlb_inv_range+0x178/0x1f0
> >> [   31.538122]  arm_smmu_iotlb_sync+0x2c/0x38
> >> [   31.542200]  iommu_unmap+0x60/0x90
> >> [   31.545585]  __iommu_map+0x110/0x1f0
> >> [   31.549144]
> iommu_create_device_direct_mappings.isra.34+0x1ac/0x250
> >> [   31.555468]  iommu_probe_device+0x6c/0x110
> >> [   31.559551]  iort_iommu_configure_id+0x114/0x218
> >> [   31.564148]  acpi_dma_configure_id+0x94/0xe0
> >> [   31.568402]  pci_dma_configure+0xc8/0xf0
> >> [   31.572310]  really_probe+0xd4/0x3e0
> >> [   31.575871]  driver_probe_device+0x5c/0xc0
> >>
> >> ---
> >>   drivers/iommu/iommu.c | 10 ++
> >>   1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> >> index b53446bb8c6b..0f4dc25d46c9 100644
> >> --- a/drivers/iommu/iommu.c
> >> +++ b/drivers/iommu/iommu.c
> >> @@ -264,16 +264,18 @@ int iommu_probe_device(struct device *dev)
> >> */
> >>iommu_alloc_default_domain(group, dev);
> >>
> >> -  if (group->default_domain)
> >> +  if (group->default_domain) {
> >>ret = __iommu_attach_device(group->default_domain, dev);
> >> +  if (ret) {
> >> +  iommu_group_put(group);
> >> +  goto err_release;
> >> +  }
> >> +  }
> >
> > This looks sensible to me, but what I don't understand is where that
> > NULL pointer is coming from in the first place. iommu_map() operates
> > on the domain, so why does it matter if the attach fails? What is being
> > accessed at arm_smmu_tlb_inv_range+0x178/0x1f0 ?
> 
> Probably because the domain is a hollow fake until the first successful
> attach - even TLB maintenance depends on having decided a pagetable format.

I think, in this particular instance, what happens is, dev reports RMR
regions (IOMMU_RESV_DIRECT) but attach_dev() fails early without
setting, smmu_domain->smmu  =  smmu.

iommu_probe_device()
  __iommu_attach_dev()  -->return err, but carries on.
  iommu_create_device_direct_mappings()
iommu_get_resv_regions()  --> dev has IOMMU_RESV_DIRECT regions
iommu_map()  
  __iommu_map()   
arm_smmu_map()  -->return err
  iommu_unmap()--> unroll on map failure
__iommu_unmap()  --> size is zero. So returns.
iommu_iotlb_sync()
  arm_smmu_iotlb_sync()
arm_smmu_tlb_inv_range()  --> smmu is NULL

Thanks,
Shameer 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH RESEND 5/5] iommu/tegra-smmu: Add PCI support

2020-11-20 Thread Thierry Reding
On Wed, Nov 11, 2020 at 02:21:29PM -0800, Nicolin Chen wrote:
> This patch simply adds support for PCI devices.
> 
> Reviewed-by: Dmitry Osipenko 
> Tested-by: Dmitry Osipenko 
> Signed-off-by: Nicolin Chen 
> ---
>  drivers/iommu/tegra-smmu.c | 35 +--
>  1 file changed, 25 insertions(+), 10 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH RESEND 4/5] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-11-20 Thread Thierry Reding
On Wed, Nov 11, 2020 at 02:21:28PM -0800, Nicolin Chen wrote:
> The bus_set_iommu() in tegra_smmu_probe() enumerates all clients
> to call in tegra_smmu_probe_device() where each client searches
> its DT node for smmu pointer and swgroup ID, so as to configure
> an fwspec. But this requires a valid smmu pointer even before mc
> and smmu drivers are probed. So in tegra_smmu_probe() we added a
> line of code to fill mc->smmu, marking "a bit of a hack".
> 
> This works for most of clients in the DTB, however, doesn't work
> for a client that doesn't exist in DTB, a PCI device for example.
> 
> Actually, if we return ERR_PTR(-ENODEV) in ->probe_device() when
> it's called from bus_set_iommu(), iommu core will let everything
> carry on. Then when a client gets probed, of_iommu_configure() in
> iommu core will search DTB for swgroup ID and call ->of_xlate()
> to prepare an fwspec, similar to tegra_smmu_probe_device() and
> tegra_smmu_configure(). Then it'll call tegra_smmu_probe_device()
> again, and this time we shall return smmu->iommu pointer properly.
> 
> So we can get rid of tegra_smmu_find() and tegra_smmu_configure()
> along with DT polling code by letting the iommu core handle every
> thing, except a problem that we search iommus property in DTB not
> only for swgroup ID but also for mc node to get mc->smmu pointer
> to call dev_iommu_priv_set() and return the smmu->iommu pointer.
> So we'll need to find another way to get smmu pointer.
> 
> Referencing the implementation of sun50i-iommu driver, of_xlate()
> has client's dev pointer, mc node and swgroup ID. This means that
> we can call dev_iommu_priv_set() in of_xlate() instead, so we can
> simply get smmu pointer in ->probe_device().
> 
> This patch reworks tegra_smmu_probe_device() by:
> 1) Removing mc->smmu hack in tegra_smmu_probe() so as to return
>ERR_PTR(-ENODEV) in tegra_smmu_probe_device() during stage of
>tegra_smmu_probe/tegra_mc_probe().
> 2) Moving dev_iommu_priv_set() to of_xlate() so we can get smmu
>pointer in tegra_smmu_probe_device() to replace DTB polling.
> 3) Removing tegra_smmu_configure() accordingly since iommu core
>takes care of it.
> 
> This also fixes a problem that previously we could add clients to
> iommu groups before iommu core initializes its default domain:
> ubuntu@jetson:~$ dmesg | grep iommu
> platform 5000.host1x: Adding to iommu group 1
> platform 5700.gpu: Adding to iommu group 2
> iommu: Default domain type: Translated
> platform 5420.dc: Adding to iommu group 3
> platform 5424.dc: Adding to iommu group 3
> platform 5434.vic: Adding to iommu group 4
> 
> Though it works fine with IOMMU_DOMAIN_UNMANAGED, but will have
> warnings if switching to IOMMU_DOMAIN_DMA:
> iommu: Failed to allocate default IOMMU domain of type 0 for
>group (null) - Falling back to IOMMU_DOMAIN_DMA
> iommu: Failed to allocate default IOMMU domain of type 0 for
>group (null) - Falling back to IOMMU_DOMAIN_DMA
> 
> Now, bypassing the first probe_device() call from bus_set_iommu()
> fixes the sequence:
> ubuntu@jetson:~$ dmesg | grep iommu
> iommu: Default domain type: Translated
> tegra-host1x 5000.host1x: Adding to iommu group 0
> tegra-dc 5420.dc: Adding to iommu group 1
> tegra-dc 5424.dc: Adding to iommu group 1
> tegra-vic 5434.vic: Adding to iommu group 2
> nouveau 5700.gpu: Adding to iommu group 3
> 
> Note that dmesg log above is testing with IOMMU_DOMAIN_UNMANAGED.
> 
> Reviewed-by: Dmitry Osipenko 
> Tested-by: Dmitry Osipenko 
> Signed-off-by: Nicolin Chen 
> ---
>  drivers/iommu/tegra-smmu.c | 96 ++
>  1 file changed, 15 insertions(+), 81 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH RESEND 3/5] iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev

2020-11-20 Thread Thierry Reding
On Wed, Nov 11, 2020 at 02:21:27PM -0800, Nicolin Chen wrote:
> In tegra_smmu_(de)attach_dev() functions, we poll DTB for each
> client's iommus property to get swgroup ID in order to prepare
> "as" and enable smmu. Actually tegra_smmu_configure() prepared
> an fwspec for each client, and added to the fwspec all swgroup
> IDs of client DT node in DTB.
> 
> So this patch uses fwspec in tegra_smmu_(de)attach_dev() so as
> to replace the redundant DT polling code.
> 
> Reviewed-by: Dmitry Osipenko 
> Tested-by: Dmitry Osipenko 
> Signed-off-by: Nicolin Chen 
> ---
>  drivers/iommu/tegra-smmu.c | 56 --
>  1 file changed, 23 insertions(+), 33 deletions(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu: Check return of __iommu_attach_device()

2020-11-20 Thread Robin Murphy

On 2020-11-20 11:15, Will Deacon wrote:

On Thu, Nov 19, 2020 at 04:58:46PM +, Shameer Kolothum wrote:

Currently iommu_create_device_direct_mappings() is called
without checking the return of __iommu_attach_device(). This
may result in failures in iommu driver if dev attach returns
error.

Fixes: ce574c27ae27("iommu: Move iommu_group_create_direct_mappings() out of 
iommu_group_add_device()")
Signed-off-by: Shameer Kolothum 
---
Crash log:
[   31.353605] hns3 :7d:00.3: Adding to iommu group 10
[   31.358822] Unable to handle kernel NULL pointer dereference at virtual 
address 0018
[   31.367567] Mem abort info:
[   31.370350]   ESR = 0x9604
[   31.373391]   EC = 0x25: DABT (current EL), IL = 32 bits
[   31.378680]   SET = 0, FnV = 0
[   31.381720]   EA = 0, S1PTW = 0
[   31.384847] Data abort info:
[   31.387716]   ISV = 0, ISS = 0x0004
[   31.391535]   CM = 0, WnR = 0
[   31.394491] [0018] user address but active_mm is swapper
[   31.400818] Internal error: Oops: 9604 [#1] PREEMPT SMP
[   31.406365] Modules linked in:
[   31.409409] CPU: 21 PID: 1 Comm: swapper/0 Not tainted 
5.10.0-rc4-8-gdd5aba9d719-dirty #79
[   31.417980] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 
2280-V2 CS V3.B220.01 03/19/2020
[   31.427588] pstate: 00c9 (nzcv daif +PAN +UAO -TCO BTYPE=--)
[   31.433566] pc : arm_smmu_tlb_inv_range+0x178/0x1f0
[   31.438422] lr : arm_smmu_tlb_inv_range+0x5c/0x1f0
[   31.443190] sp : 80001043b4e0
...
[   31.531175] Call trace:
[   31.533613]  arm_smmu_tlb_inv_range+0x178/0x1f0
[   31.538122]  arm_smmu_iotlb_sync+0x2c/0x38
[   31.542200]  iommu_unmap+0x60/0x90
[   31.545585]  __iommu_map+0x110/0x1f0
[   31.549144]  iommu_create_device_direct_mappings.isra.34+0x1ac/0x250
[   31.555468]  iommu_probe_device+0x6c/0x110
[   31.559551]  iort_iommu_configure_id+0x114/0x218
[   31.564148]  acpi_dma_configure_id+0x94/0xe0
[   31.568402]  pci_dma_configure+0xc8/0xf0
[   31.572310]  really_probe+0xd4/0x3e0
[   31.575871]  driver_probe_device+0x5c/0xc0

---
  drivers/iommu/iommu.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b53446bb8c6b..0f4dc25d46c9 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -264,16 +264,18 @@ int iommu_probe_device(struct device *dev)
 */
iommu_alloc_default_domain(group, dev);
  
-	if (group->default_domain)

+   if (group->default_domain) {
ret = __iommu_attach_device(group->default_domain, dev);
+   if (ret) {
+   iommu_group_put(group);
+   goto err_release;
+   }
+   }


This looks sensible to me, but what I don't understand is where that
NULL pointer is coming from in the first place. iommu_map() operates
on the domain, so why does it matter if the attach fails? What is being
accessed at arm_smmu_tlb_inv_range+0x178/0x1f0 ?


Probably because the domain is a hollow fake until the first successful 
attach - even TLB maintenance depends on having decided a pagetable format.


Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-20 Thread Lu Baolu

Hi Chris,

On 2020/11/20 20:24, Chris Wilson wrote:

Quoting Lu Baolu (2020-11-20 10:17:12)

Lu Baolu (3):
   iommu: Add quirk for Intel graphic devices in map_sg
   iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
   iommu/vt-d: Cleanup after converting to dma-iommu ops

Tom Murphy (4):
   iommu: Handle freelists when using deferred flushing in iommu drivers
   iommu: Add iommu_dma_free_cpu_cached_iovas()
   iommu: Allow the dma-iommu api to use bounce buffers
   iommu/vt-d: Convert intel iommu driver to the iommu ops


Something that may be of interest is that we encounter problems with
using intel-iommu across a PCI remove event. All HW generations fail
with faults like:

DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Write] Request device [00:02.0] PASID  fault addr 4b822000 
[fault reason 02] Present bit in context entry is clear

i.e. they all report missing present bit after re-adding the device to the
iommu group. Forcing an identity map (or disabling iommu) works fine.

I applied this series just on the off-chance it changed the symptoms; it
does not. If you have any ideas on how to chase down this fault, that
would be very useful. We have a few other DMAR faults visible on many
platforms, all "[fault reason 07] Next page table ptr is invalid" that
are again not affected by this series, that we also need to resolve.


This series only replaces the previous vt-d self-made dma api's with the
generic one (which has already been used by some other vendor iommu
drivers). It shouldn't solve the problem you're having.

How about reporting them in https://bugzilla.kernel.org/? I have
interests to help to figure out possible fixes.


-Chris



Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [Patch V8 1/3] iommu: Add support to change default domain of an iommu group

2020-11-20 Thread Lu Baolu

Hi Shameer,

On 2020/11/20 19:27, Shameerali Kolothum Thodi wrote:

Hi Baolu/Ashok,


-Original Message-
From: iommu [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of
Ashok Raj
Sent: 25 September 2020 20:06
To: Joerg Roedel ; iommu@lists.linux-foundation.org
Cc: Ashok Raj ; Will Deacon ;
Robin Murphy ; Christoph Hellwig 
Subject: [Patch V8 1/3] iommu: Add support to change default domain of an
iommu group

From: Sai Praneeth Prakhya 

Presently, the default domain of an iommu group is allocated during boot
time and it cannot be changed later. So, the device would typically be
either in identity (also known as pass_through) mode or the device would be
in DMA mode as long as the machine is up and running. There is no way to
change the default domain type dynamically i.e. after booting, a device
cannot switch between identity mode and DMA mode.

But, assume a use case wherein the user trusts the device and believes that
the OS is secure enough and hence wants *only* this device to bypass IOMMU
(so that it could be high performing) whereas all the other devices to go
through IOMMU (so that the system is protected). Presently, this use case
is not supported. It will be helpful if there is some way to change the
default domain of an iommu group dynamically. Hence, add such support.

A privileged user could request the kernel to change the default domain
type of a iommu group by writing to
"/sys/kernel/iommu_groups//type" file. Presently, only three values
are supported
1. identity: all the DMA transactions from the device in this group are
  *not* translated by the iommu
2. DMA: all the DMA transactions from the device in this group are
 translated by the iommu
3. auto: change to the type the device was booted with

Note:
1. Default domain of an iommu group with two or more devices cannot be
changed.
2. The device in the iommu group shouldn't be bound to any driver.
3. The device shouldn't be assigned to user for direct access.
4. The vendor iommu driver is required to add def_domain_type() callback.
The change request will fail if the request type conflicts with that
returned from the callback.


Currently Arm SMMUv3 driver doesn't provide the def_doman_type() callback.
And I have sent a patch[1] based on this series to just add that. But Robin made
couple of suggestions there which can be incorporated into this series so that 
the
vendor driver no more required to provide the callback for this feature to work.

1. Include a generic checking for
if (dev_is_pci(dev)) {
if (pci_dev->untrusted)
return IOMMU_DOMAIN_DMA;
}


To be honest, I have the same idea. Okay! I can do this in the next
version.



2. Also if there is no def_doman_type() callback provided by vendor driver, 
assume
   that the dev supports both IDENTITY and DMA domain types.


It's true for boot case. I will assume this in this series.



If you plan to respin this series, could you please consider the above as well?
Please let me know.


Sure!



Thanks,
Shameer


Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-20 Thread Chris Wilson
Quoting Lu Baolu (2020-11-20 10:17:12)
> Lu Baolu (3):
>   iommu: Add quirk for Intel graphic devices in map_sg
>   iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
>   iommu/vt-d: Cleanup after converting to dma-iommu ops
> 
> Tom Murphy (4):
>   iommu: Handle freelists when using deferred flushing in iommu drivers
>   iommu: Add iommu_dma_free_cpu_cached_iovas()
>   iommu: Allow the dma-iommu api to use bounce buffers
>   iommu/vt-d: Convert intel iommu driver to the iommu ops

Something that may be of interest is that we encounter problems with
using intel-iommu across a PCI remove event. All HW generations fail
with faults like:

DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Write] Request device [00:02.0] PASID  fault addr 4b822000 
[fault reason 02] Present bit in context entry is clear

i.e. they all report missing present bit after re-adding the device to the
iommu group. Forcing an identity map (or disabling iommu) works fine.

I applied this series just on the off-chance it changed the symptoms; it
does not. If you have any ideas on how to chase down this fault, that
would be very useful. We have a few other DMAR faults visible on many
platforms, all "[fault reason 07] Next page table ptr is invalid" that
are again not affected by this series, that we also need to resolve.
-Chris
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[GIT PULL] IOMMU fixes for -rc5

2020-11-20 Thread Will Deacon
Hi Linus,

As mentioned at [1], I'm temporarily helping out with the IOMMU tree so
here are some fixes I've collected for -rc5, including an update to
MAINTAINERS as suggested by Joerg on IRC.

Anyway, two straightforward vt-d fixes summarised in the tag. I ended up
pulling in some x86 fixes from tip which you already merged for -rc4, as
the DMAR build failure was introduced there and so I needed that in order
to apply the fix.

Please pull.

Cheers,

Will

[1] https://lore.kernel.org/lkml/20201117100953.gr22...@8bytes.org/

--->8

The following changes since commit ff828729be446b86957f7c294068758231cd2183:

  iommu/vt-d: Cure VF irqdomain hickup (2020-11-13 12:00:40 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/iommu-fixes

for you to fetch changes up to 91c2c28d8de34815ea9bb4d16e9db7308ad33d3e:

  MAINTAINERS: Temporarily add myself to the IOMMU entry (2020-11-19 11:12:17 
+)


iommu fixes for -rc5

- Fix boot when intel iommu initialisation fails under TXT (tboot)

- Fix intel iommu compilation error when DMAR is enabled without ATS

- Temporarily update IOMMU MAINTAINERs entry


Lu Baolu (1):
  iommu/vt-d: Fix compile error with CONFIG_PCI_ATS not set

Will Deacon (2):
  Merge tag 'x86-urgent-2020-11-15' of git://git.kernel.org/.../tip/tip 
into for-next/iommu/fixes
  MAINTAINERS: Temporarily add myself to the IOMMU entry

Zhenzhong Duan (1):
  iommu/vt-d: Avoid panic if iommu init fails in tboot system

 MAINTAINERS | 1 +
 arch/x86/kernel/tboot.c | 3 ---
 drivers/iommu/intel/dmar.c  | 4 +++-
 drivers/iommu/intel/iommu.c | 5 +++--
 include/linux/intel-iommu.h | 1 -
 5 files changed, 7 insertions(+), 7 deletions(-)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu: Check return of __iommu_attach_device()

2020-11-20 Thread Will Deacon
On Thu, Nov 19, 2020 at 04:58:46PM +, Shameer Kolothum wrote:
> Currently iommu_create_device_direct_mappings() is called
> without checking the return of __iommu_attach_device(). This
> may result in failures in iommu driver if dev attach returns
> error.
> 
> Fixes: ce574c27ae27("iommu: Move iommu_group_create_direct_mappings() out of 
> iommu_group_add_device()")
> Signed-off-by: Shameer Kolothum 
> ---
> Crash log:
> [   31.353605] hns3 :7d:00.3: Adding to iommu group 10
> [   31.358822] Unable to handle kernel NULL pointer dereference at virtual 
> address 0018
> [   31.367567] Mem abort info:
> [   31.370350]   ESR = 0x9604
> [   31.373391]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   31.378680]   SET = 0, FnV = 0
> [   31.381720]   EA = 0, S1PTW = 0
> [   31.384847] Data abort info:
> [   31.387716]   ISV = 0, ISS = 0x0004
> [   31.391535]   CM = 0, WnR = 0
> [   31.394491] [0018] user address but active_mm is swapper
> [   31.400818] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [   31.406365] Modules linked in:
> [   31.409409] CPU: 21 PID: 1 Comm: swapper/0 Not tainted 
> 5.10.0-rc4-8-gdd5aba9d719-dirty #79
> [   31.417980] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 
> 2280-V2 CS V3.B220.01 03/19/2020
> [   31.427588] pstate: 00c9 (nzcv daif +PAN +UAO -TCO BTYPE=--)
> [   31.433566] pc : arm_smmu_tlb_inv_range+0x178/0x1f0
> [   31.438422] lr : arm_smmu_tlb_inv_range+0x5c/0x1f0
> [   31.443190] sp : 80001043b4e0
> ...
> [   31.531175] Call trace:
> [   31.533613]  arm_smmu_tlb_inv_range+0x178/0x1f0
> [   31.538122]  arm_smmu_iotlb_sync+0x2c/0x38
> [   31.542200]  iommu_unmap+0x60/0x90
> [   31.545585]  __iommu_map+0x110/0x1f0
> [   31.549144]  iommu_create_device_direct_mappings.isra.34+0x1ac/0x250
> [   31.555468]  iommu_probe_device+0x6c/0x110
> [   31.559551]  iort_iommu_configure_id+0x114/0x218
> [   31.564148]  acpi_dma_configure_id+0x94/0xe0
> [   31.568402]  pci_dma_configure+0xc8/0xf0
> [   31.572310]  really_probe+0xd4/0x3e0
> [   31.575871]  driver_probe_device+0x5c/0xc0
> 
> ---
>  drivers/iommu/iommu.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index b53446bb8c6b..0f4dc25d46c9 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -264,16 +264,18 @@ int iommu_probe_device(struct device *dev)
>*/
>   iommu_alloc_default_domain(group, dev);
>  
> - if (group->default_domain)
> + if (group->default_domain) {
>   ret = __iommu_attach_device(group->default_domain, dev);
> + if (ret) {
> + iommu_group_put(group);
> + goto err_release;
> + }
> + }

This looks sensible to me, but what I don't understand is where that
NULL pointer is coming from in the first place. iommu_map() operates
on the domain, so why does it matter if the attach fails? What is being
accessed at arm_smmu_tlb_inv_range+0x178/0x1f0 ?

Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [Patch V8 1/3] iommu: Add support to change default domain of an iommu group

2020-11-20 Thread Will Deacon
On Fri, Nov 20, 2020 at 10:11:58AM +0800, Lu Baolu wrote:
> On 11/19/20 4:53 PM, Will Deacon wrote:
> > On Thu, Nov 19, 2020 at 10:18:05AM +0800, Lu Baolu wrote:
> > > On 11/18/20 9:51 PM, Will Deacon wrote:
> > > > On Fri, Sep 25, 2020 at 12:06:18PM -0700, Ashok Raj wrote:
> > > > > From: Sai Praneeth Prakhya 
> > 
> > [...]
> > 
> > > > > +free_new_domain:
> > > > > + iommu_domain_free(group->default_domain);
> > > > > + group->default_domain = prev_dom;
> > > > > + group->domain = prev_dom;i
> > > > 
> > > > Hmm. This seems to rely on all users of group->default_domain holding 
> > > > the
> > > > group->mutex. Have you confirmed that this is the case? There's a funny
> > > > use of iommu_group_get() in the exynos IOMMU driver at least.
> > > 
> > > Emm. This change happens within the area with group->mutex held. Or I
> > > am not getting your point?
> > 
> > Yeah, sorry, I wasn't very clear. This code holds the group->mutex, and it
> > relies on _anybody_ else who wants to inspect group->default_domain also
> > holding that mutex, otherwise they could observe a transient domain pointer
> > which we free on the failure path here.
> 
> Clear to me now. Thanks for explanation. :-)
> 
> Changing default domain through sysfs requires the users to ubind any
> driver from the devices in the group. There's a check code and return
> failure if this requirement doesn't meet.
> 
> So we only need to consider the device release path. device_lock(dev) is
> used in this patch to guarantee that no device release happens at the
> same time.

Aha, thanks. Please can you add a comment for future reference?

> 
> > 
> > My question is whether or not there is code that inspects
> > group->default_domain without group->mutex held? The exynos case doesn't
> > obviously hold it, and I'd like to make sure that there aren't others that
> > we need to worry about.
> 
> I searched the code. The exynos is the only case that inspects
> group->default_domain without holding the mutex during run time. It's in
> the device release path, so I think it's safe.

Great, thanks for looking.

Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v5 6/7] iommu/vt-d: Convert intel iommu driver to the iommu ops

2020-11-20 Thread Lu Baolu
From: Tom Murphy 

Convert the intel iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the intel iommu driver.

Signed-off-by: Tom Murphy 
Signed-off-by: Lu Baolu 
Tested-by: Logan Gunthorpe 
---
 drivers/iommu/intel/Kconfig |   1 +
 drivers/iommu/intel/iommu.c | 746 ++--
 2 files changed, 43 insertions(+), 704 deletions(-)

diff --git a/drivers/iommu/intel/Kconfig b/drivers/iommu/intel/Kconfig
index 5337ee1584b0..28a3d1596c76 100644
--- a/drivers/iommu/intel/Kconfig
+++ b/drivers/iommu/intel/Kconfig
@@ -13,6 +13,7 @@ config INTEL_IOMMU
select DMAR_TABLE
select SWIOTLB
select IOASID
+   select IOMMU_DMA
help
  DMA remapping (DMAR) devices support enables independent address
  translations for Direct Memory Access (DMA) from devices.
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 80a7e4e1781b..7b36b48b9887 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -382,9 +382,6 @@ struct device_domain_info *get_domain_info(struct device 
*dev)
 DEFINE_SPINLOCK(device_domain_lock);
 static LIST_HEAD(device_domain_list);
 
-#define device_needs_bounce(d) (!intel_no_bounce && dev_is_pci(d) &&   \
-   to_pci_dev(d)->untrusted)
-
 /*
  * Iterate over elements in device_domain_list and call the specified
  * callback @fn against each element.
@@ -1289,13 +1286,6 @@ static void dma_free_pagelist(struct page *freelist)
}
 }
 
-static void iova_entry_free(unsigned long data)
-{
-   struct page *freelist = (struct page *)data;
-
-   dma_free_pagelist(freelist);
-}
-
 /* iommu handling */
 static int iommu_alloc_root_entry(struct intel_iommu *iommu)
 {
@@ -1660,19 +1650,17 @@ static inline void __mapping_notify_one(struct 
intel_iommu *iommu,
iommu_flush_write_buffer(iommu);
 }
 
-static void iommu_flush_iova(struct iova_domain *iovad)
+static void intel_flush_iotlb_all(struct iommu_domain *domain)
 {
-   struct dmar_domain *domain;
+   struct dmar_domain *dmar_domain = to_dmar_domain(domain);
int idx;
 
-   domain = container_of(iovad, struct dmar_domain, iovad);
-
-   for_each_domain_iommu(idx, domain) {
+   for_each_domain_iommu(idx, dmar_domain) {
struct intel_iommu *iommu = g_iommus[idx];
-   u16 did = domain->iommu_did[iommu->seq_id];
+   u16 did = dmar_domain->iommu_did[iommu->seq_id];
 
-   if (domain_use_first_level(domain))
-   domain_flush_piotlb(iommu, domain, 0, -1, 0);
+   if (domain_use_first_level(dmar_domain))
+   domain_flush_piotlb(iommu, dmar_domain, 0, -1, 0);
else
iommu->flush.flush_iotlb(iommu, did, 0, 0,
 DMA_TLB_DSI_FLUSH);
@@ -1954,48 +1942,6 @@ static int domain_detach_iommu(struct dmar_domain 
*domain,
return count;
 }
 
-static struct iova_domain reserved_iova_list;
-static struct lock_class_key reserved_rbtree_key;
-
-static int dmar_init_reserved_ranges(void)
-{
-   struct pci_dev *pdev = NULL;
-   struct iova *iova;
-   int i;
-
-   init_iova_domain(_iova_list, VTD_PAGE_SIZE, IOVA_START_PFN);
-
-   lockdep_set_class(_iova_list.iova_rbtree_lock,
-   _rbtree_key);
-
-   /* IOAPIC ranges shouldn't be accessed by DMA */
-   iova = reserve_iova(_iova_list, IOVA_PFN(IOAPIC_RANGE_START),
-   IOVA_PFN(IOAPIC_RANGE_END));
-   if (!iova) {
-   pr_err("Reserve IOAPIC range failed\n");
-   return -ENODEV;
-   }
-
-   /* Reserve all PCI MMIO to avoid peer-to-peer access */
-   for_each_pci_dev(pdev) {
-   struct resource *r;
-
-   for (i = 0; i < PCI_NUM_RESOURCES; i++) {
-   r = >resource[i];
-   if (!r->flags || !(r->flags & IORESOURCE_MEM))
-   continue;
-   iova = reserve_iova(_iova_list,
-   IOVA_PFN(r->start),
-   IOVA_PFN(r->end));
-   if (!iova) {
-   pci_err(pdev, "Reserve iova for %pR failed\n", 
r);
-   return -ENODEV;
-   }
-   }
-   }
-   return 0;
-}
-
 static inline int guestwidth_to_adjustwidth(int gaw)
 {
int agaw;
@@ -2018,7 +1964,7 @@ static void domain_exit(struct dmar_domain *domain)
 
/* destroy iovas */
if (domain->domain.type == IOMMU_DOMAIN_DMA)
-   put_iova_domain(>iovad);
+   

[PATCH v5 7/7] iommu/vt-d: Cleanup after converting to dma-iommu ops

2020-11-20 Thread Lu Baolu
Some cleanups after converting the driver to use dma-iommu ops.
- Remove nobounce option;
- Cleanup and simplify the path in domain mapping.

Signed-off-by: Lu Baolu 
Tested-by: Logan Gunthorpe 
---
 .../admin-guide/kernel-parameters.txt |  5 --
 drivers/iommu/intel/iommu.c   | 90 ++-
 2 files changed, 28 insertions(+), 67 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..76b2a2063fd0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1883,11 +1883,6 @@
Note that using this option lowers the security
provided by tboot because it makes the system
vulnerable to DMA attacks.
-   nobounce [Default off]
-   Disable bounce buffer for untrusted devices such as
-   the Thunderbolt devices. This will treat the untrusted
-   devices as the trusted ones, hence might expose security
-   risks of DMA attacks.
 
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 7b36b48b9887..e81fdbf79b96 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -355,7 +355,6 @@ static int dmar_forcedac;
 static int intel_iommu_strict;
 static int intel_iommu_superpage = 1;
 static int iommu_identity_mapping;
-static int intel_no_bounce;
 static int iommu_skip_te_disable;
 
 #define IDENTMAP_GFX   2
@@ -457,9 +456,6 @@ static int __init intel_iommu_setup(char *str)
} else if (!strncmp(str, "tboot_noforce", 13)) {
pr_info("Intel-IOMMU: not forcing on after tboot. This 
could expose security risk for tboot\n");
intel_iommu_tboot_noforce = 1;
-   } else if (!strncmp(str, "nobounce", 8)) {
-   pr_info("Intel-IOMMU: No bounce buffer. This could 
expose security risks of DMA attacks\n");
-   intel_no_bounce = 1;
}
 
str += strcspn(str, ",");
@@ -2277,15 +2273,14 @@ static inline int hardware_largepage_caps(struct 
dmar_domain *domain,
return level;
 }
 
-static int __domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
-   struct scatterlist *sg, unsigned long phys_pfn,
-   unsigned long nr_pages, int prot)
+static int
+__domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
+unsigned long phys_pfn, unsigned long nr_pages, int prot)
 {
struct dma_pte *first_pte = NULL, *pte = NULL;
-   phys_addr_t pteval;
-   unsigned long sg_res = 0;
unsigned int largepage_lvl = 0;
unsigned long lvl_pages = 0;
+   phys_addr_t pteval;
u64 attr;
 
BUG_ON(!domain_pfn_supported(domain, iov_pfn + nr_pages - 1));
@@ -2297,26 +2292,14 @@ static int __domain_mapping(struct dmar_domain *domain, 
unsigned long iov_pfn,
if (domain_use_first_level(domain))
attr |= DMA_FL_PTE_PRESENT | DMA_FL_PTE_XD | DMA_FL_PTE_US;
 
-   if (!sg) {
-   sg_res = nr_pages;
-   pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
-   }
+   pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
 
while (nr_pages > 0) {
uint64_t tmp;
 
-   if (!sg_res) {
-   unsigned int pgoff = sg->offset & ~PAGE_MASK;
-
-   sg_res = aligned_nrpages(sg->offset, sg->length);
-   sg->dma_address = ((dma_addr_t)iov_pfn << 
VTD_PAGE_SHIFT) + pgoff;
-   sg->dma_length = sg->length;
-   pteval = (sg_phys(sg) - pgoff) | attr;
-   phys_pfn = pteval >> VTD_PAGE_SHIFT;
-   }
-
if (!pte) {
-   largepage_lvl = hardware_largepage_caps(domain, 
iov_pfn, phys_pfn, sg_res);
+   largepage_lvl = hardware_largepage_caps(domain, iov_pfn,
+   phys_pfn, nr_pages);
 
first_pte = pte = pfn_to_dma_pte(domain, iov_pfn, 
_lvl);
if (!pte)
@@ -2328,7 +2311,7 @@ static int __domain_mapping(struct dmar_domain *domain, 
unsigned long iov_pfn,
pteval |= DMA_PTE_LARGE_PAGE;
lvl_pages = lvl_to_nr_pages(largepage_lvl);
 
-   nr_superpages = sg_res / lvl_pages;
+   nr_superpages = nr_pages / lvl_pages;
end_pfn = iov_pfn + nr_superpages * lvl_pages - 
1;
 
/*

[PATCH v5 3/7] iommu: Allow the dma-iommu api to use bounce buffers

2020-11-20 Thread Lu Baolu
From: Tom Murphy 

Allow the dma-iommu api to use bounce buffers for untrusted devices.
This is a copy of the intel bounce buffer code.

Signed-off-by: Tom Murphy 
Co-developed-by: Lu Baolu 
Signed-off-by: Lu Baolu 
Tested-by: Logan Gunthorpe 
---
 drivers/iommu/dma-iommu.c | 163 +++---
 1 file changed, 150 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index de521e22bafb..10dafbc3d9e0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -20,9 +20,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 struct iommu_dma_msi_page {
struct list_headlist;
@@ -499,6 +501,31 @@ static void __iommu_dma_unmap(struct device *dev, 
dma_addr_t dma_addr,
iommu_dma_free_iova(cookie, dma_addr, size, iotlb_gather.freelist);
 }
 
+static void __iommu_dma_unmap_swiotlb(struct device *dev, dma_addr_t dma_addr,
+   size_t size, enum dma_data_direction dir,
+   unsigned long attrs)
+{
+   struct iommu_domain *domain = iommu_get_dma_domain(dev);
+   struct iommu_dma_cookie *cookie = domain->iova_cookie;
+   struct iova_domain *iovad = >iovad;
+   phys_addr_t phys;
+
+   phys = iommu_iova_to_phys(domain, dma_addr);
+   if (WARN_ON(!phys))
+   return;
+
+   __iommu_dma_unmap(dev, dma_addr, size);
+
+   if (unlikely(is_swiotlb_buffer(phys)))
+   swiotlb_tbl_unmap_single(dev, phys, size,
+   iova_align(iovad, size), dir, attrs);
+}
+
+static bool dev_is_untrusted(struct device *dev)
+{
+   return dev_is_pci(dev) && to_pci_dev(dev)->untrusted;
+}
+
 static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
size_t size, int prot, u64 dma_mask)
 {
@@ -524,6 +551,55 @@ static dma_addr_t __iommu_dma_map(struct device *dev, 
phys_addr_t phys,
return iova + iova_off;
 }
 
+static dma_addr_t __iommu_dma_map_swiotlb(struct device *dev, phys_addr_t phys,
+   size_t org_size, dma_addr_t dma_mask, bool coherent,
+   enum dma_data_direction dir, unsigned long attrs)
+{
+   int prot = dma_info_to_prot(dir, coherent, attrs);
+   struct iommu_domain *domain = iommu_get_dma_domain(dev);
+   struct iommu_dma_cookie *cookie = domain->iova_cookie;
+   struct iova_domain *iovad = >iovad;
+   size_t aligned_size = org_size;
+   void *padding_start;
+   size_t padding_size;
+   dma_addr_t iova;
+
+   /*
+* If both the physical buffer start address and size are
+* page aligned, we don't need to use a bounce page.
+*/
+   if (IS_ENABLED(CONFIG_SWIOTLB) && dev_is_untrusted(dev) &&
+   iova_offset(iovad, phys | org_size)) {
+   aligned_size = iova_align(iovad, org_size);
+   phys = swiotlb_tbl_map_single(dev,
+   phys_to_dma(dev, io_tlb_start),
+   phys, org_size, aligned_size, dir, attrs);
+
+   if (phys == DMA_MAPPING_ERROR)
+   return DMA_MAPPING_ERROR;
+
+   /* Cleanup the padding area. */
+   padding_start = phys_to_virt(phys);
+   padding_size = aligned_size;
+
+   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+   (dir == DMA_TO_DEVICE ||
+dir == DMA_BIDIRECTIONAL)) {
+   padding_start += org_size;
+   padding_size -= org_size;
+   }
+
+   memset(padding_start, 0, padding_size);
+   }
+
+   iova = __iommu_dma_map(dev, phys, aligned_size, prot, dma_mask);
+   if ((iova == DMA_MAPPING_ERROR) && is_swiotlb_buffer(phys))
+   swiotlb_tbl_unmap_single(dev, phys, org_size,
+   aligned_size, dir, attrs);
+
+   return iova;
+}
+
 static void __iommu_dma_free_pages(struct page **pages, int count)
 {
while (count--)
@@ -697,11 +773,15 @@ static void iommu_dma_sync_single_for_cpu(struct device 
*dev,
 {
phys_addr_t phys;
 
-   if (dev_is_dma_coherent(dev))
+   if (dev_is_dma_coherent(dev) && !dev_is_untrusted(dev))
return;
 
phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle);
-   arch_sync_dma_for_cpu(phys, size, dir);
+   if (!dev_is_dma_coherent(dev))
+   arch_sync_dma_for_cpu(phys, size, dir);
+
+   if (is_swiotlb_buffer(phys))
+   swiotlb_tbl_sync_single(dev, phys, size, dir, SYNC_FOR_CPU);
 }
 
 static void iommu_dma_sync_single_for_device(struct device *dev,
@@ -709,11 +789,15 @@ static void iommu_dma_sync_single_for_device(struct 
device *dev,
 {
phys_addr_t phys;
 
-   if (dev_is_dma_coherent(dev))
+   if (dev_is_dma_coherent(dev) && !dev_is_untrusted(dev))
return;
 
phys = 

[PATCH v5 5/7] iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev

2020-11-20 Thread Lu Baolu
The iommu-dma constrains IOVA allocation based on the domain geometry
that the driver reports. Update domain geometry everytime a domain is
attached to or detached from a device.

Signed-off-by: Lu Baolu 
Tested-by: Logan Gunthorpe 
---
 drivers/iommu/intel/iommu.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 77fba7f8336a..80a7e4e1781b 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -67,8 +67,8 @@
 #define MAX_AGAW_WIDTH 64
 #define MAX_AGAW_PFN_WIDTH (MAX_AGAW_WIDTH - VTD_PAGE_SHIFT)
 
-#define __DOMAIN_MAX_PFN(gaw)  uint64_t)1) << (gaw-VTD_PAGE_SHIFT)) - 1)
-#define __DOMAIN_MAX_ADDR(gaw) uint64_t)1) << gaw) - 1)
+#define __DOMAIN_MAX_PFN(gaw)  uint64_t)1) << ((gaw) - VTD_PAGE_SHIFT)) - 
1)
+#define __DOMAIN_MAX_ADDR(gaw) uint64_t)1) << (gaw)) - 1)
 
 /* We limit DOMAIN_MAX_PFN to fit in an unsigned long, and DOMAIN_MAX_ADDR
to match. That way, we can use 'unsigned long' for PFNs with impunity. */
@@ -739,6 +739,18 @@ static void domain_update_iommu_cap(struct dmar_domain 
*domain)
 */
if (domain->nid == NUMA_NO_NODE)
domain->nid = domain_update_device_node(domain);
+
+   /*
+* First-level translation restricts the input-address to a
+* canonical address (i.e., address bits 63:N have the same
+* value as address bit [N-1], where N is 48-bits with 4-level
+* paging and 57-bits with 5-level paging). Hence, skip bit
+* [N-1].
+*/
+   if (domain_use_first_level(domain))
+   domain->domain.geometry.aperture_end = 
__DOMAIN_MAX_ADDR(domain->gaw - 1);
+   else
+   domain->domain.geometry.aperture_end = 
__DOMAIN_MAX_ADDR(domain->gaw);
 }
 
 struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus,
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v5 4/7] iommu: Add quirk for Intel graphic devices in map_sg

2020-11-20 Thread Lu Baolu
Combining the sg segments exposes a bug in the Intel i915 driver which
causes visual artifacts and the screen to freeze. This is most likely
because of how the i915 handles the returned list. It probably doesn't
respect the returned value specifying the number of elements in the list
and instead depends on the previous behaviour of the Intel iommu driver
which would return the same number of elements in the output list as in
the input list.

Signed-off-by: Tom Murphy 
Signed-off-by: Lu Baolu 
Tested-by: Logan Gunthorpe 
---
 drivers/iommu/dma-iommu.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 10dafbc3d9e0..5591d6593583 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -879,6 +879,33 @@ static int __finalise_sg(struct device *dev, struct 
scatterlist *sg, int nents,
unsigned int cur_len = 0, max_len = dma_get_max_seg_size(dev);
int i, count = 0;
 
+   /*
+* The Intel graphic driver is used to assume that the returned
+* sg list is not combound. This blocks the efforts of converting
+* Intel IOMMU driver to dma-iommu api's. Add this quirk to make the
+* device driver work and should be removed once it's fixed in i915
+* driver.
+*/
+   if (IS_ENABLED(CONFIG_DRM_I915) && dev_is_pci(dev) &&
+   to_pci_dev(dev)->vendor == PCI_VENDOR_ID_INTEL &&
+   (to_pci_dev(dev)->class >> 16) == PCI_BASE_CLASS_DISPLAY) {
+   for_each_sg(sg, s, nents, i) {
+   unsigned int s_iova_off = sg_dma_address(s);
+   unsigned int s_length = sg_dma_len(s);
+   unsigned int s_iova_len = s->length;
+
+   s->offset += s_iova_off;
+   s->length = s_length;
+   sg_dma_address(s) = dma_addr + s_iova_off;
+   sg_dma_len(s) = s_length;
+   dma_addr += s_iova_len;
+
+   pr_info_once("sg combining disabled due to i915 
driver\n");
+   }
+
+   return nents;
+   }
+
for_each_sg(sg, s, nents, i) {
/* Restore this segment's original unaligned fields first */
unsigned int s_iova_off = sg_dma_address(s);
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v5 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-20 Thread Lu Baolu
Hi Will,

The previous post of this series could be found here.

https://lore.kernel.org/linux-iommu/20200927063437.13988-1-baolu...@linux.intel.com/

Changes in this version:
- Add Tested-by: Logan Gunthorpe 
- Rebase to v5.10-rc3

Please review and consider it for iommu/next.

Best regards,
baolu

Lu Baolu (3):
  iommu: Add quirk for Intel graphic devices in map_sg
  iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
  iommu/vt-d: Cleanup after converting to dma-iommu ops

Tom Murphy (4):
  iommu: Handle freelists when using deferred flushing in iommu drivers
  iommu: Add iommu_dma_free_cpu_cached_iovas()
  iommu: Allow the dma-iommu api to use bounce buffers
  iommu/vt-d: Convert intel iommu driver to the iommu ops

 .../admin-guide/kernel-parameters.txt |   5 -
 drivers/iommu/dma-iommu.c | 228 -
 drivers/iommu/intel/Kconfig   |   1 +
 drivers/iommu/intel/iommu.c   | 905 +++---
 include/linux/dma-iommu.h |   8 +
 include/linux/iommu.h |   1 +
 6 files changed, 336 insertions(+), 812 deletions(-)

-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v5 2/7] iommu: Add iommu_dma_free_cpu_cached_iovas()

2020-11-20 Thread Lu Baolu
From: Tom Murphy 

Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which
use the dma-iommu ops to free cached cpu iovas.

Signed-off-by: Tom Murphy 
Signed-off-by: Lu Baolu 
Tested-by: Logan Gunthorpe 
---
 drivers/iommu/dma-iommu.c | 9 +
 include/linux/dma-iommu.h | 8 
 2 files changed, 17 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9c827a4d2207..de521e22bafb 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -49,6 +49,15 @@ struct iommu_dma_cookie {
struct iommu_domain *fq_domain;
 };
 
+void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
+   struct iommu_domain *domain)
+{
+   struct iommu_dma_cookie *cookie = domain->iova_cookie;
+   struct iova_domain *iovad = >iovad;
+
+   free_cpu_cached_iovas(cpu, iovad);
+}
+
 static void iommu_dma_entry_dtor(unsigned long data)
 {
struct page *freelist = (struct page *)data;
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 2112f21f73d8..706b68d1359b 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -37,6 +37,9 @@ void iommu_dma_compose_msi_msg(struct msi_desc *desc,
 
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
+void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
+   struct iommu_domain *domain);
+
 #else /* CONFIG_IOMMU_DMA */
 
 struct iommu_domain;
@@ -78,5 +81,10 @@ static inline void iommu_dma_get_resv_regions(struct device 
*dev, struct list_he
 {
 }
 
+static inline void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
+   struct iommu_domain *domain)
+{
+}
+
 #endif /* CONFIG_IOMMU_DMA */
 #endif /* __DMA_IOMMU_H */
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

2020-11-20 Thread Lu Baolu

On 2020/11/3 18:54, Joerg Roedel wrote:

Hi,

On Tue, Nov 03, 2020 at 11:58:26AM +0200, Joonas Lahtinen wrote:

Would that work for you? We intend to send the feature pull requests
to DRM for 5.11 in the upcoming weeks.


For the IOMMU side it is best to include the workaround for now. When
the DRM fixes are merged into v5.11-rc1 together with this conversion,
it can be reverted and will not be in 5.11-final.


Okay! So I will keep the workaround and send a new version (mostly
rebase) to Will.

Best regards,
baolu

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: Improve the performance for direct_mapping

2020-11-20 Thread Yong Wu
Currently direct_mapping always use the smallest pgsize which is SZ_4K
normally to mapping. This is unnecessary. we could gather the size, and
call iommu_map then, iommu_map could decide how to map better with the
just right pgsize.

>From the original comment, we should take care overlap, otherwise,
iommu_map may return -EEXIST. In this overlap case, we should map the
previous region before overlap firstly. then map the left part.

Each a iommu device will call this direct_mapping when its iommu
initialize, This patch is effective to improve the boot/initialization
time especially while it only needs level 1 mapping.

Signed-off-by: Anan Sun 
Signed-off-by: Yong Wu 
---
 drivers/iommu/iommu.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index df87c8e825f7..854a8fcb928d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -737,6 +737,7 @@ static int iommu_create_device_direct_mappings(struct 
iommu_group *group,
/* We need to consider overlapping regions for different devices */
list_for_each_entry(entry, , list) {
dma_addr_t start, end, addr;
+   size_t unmapped_sz = 0;
 
if (domain->ops->apply_resv_region)
domain->ops->apply_resv_region(dev, domain, entry);
@@ -752,10 +753,25 @@ static int iommu_create_device_direct_mappings(struct 
iommu_group *group,
phys_addr_t phys_addr;
 
phys_addr = iommu_iova_to_phys(domain, addr);
-   if (phys_addr)
+   if (phys_addr == 0) {
+   unmapped_sz += pg_size; /* Gather the size. */
continue;
+   }
 
-   ret = iommu_map(domain, addr, addr, pg_size, 
entry->prot);
+   if (unmapped_sz) {
+   /* Map the region before the overlap. */
+   ret = iommu_map(domain, start, start,
+   unmapped_sz, entry->prot);
+   if (ret)
+   goto out;
+   start += unmapped_sz;
+   unmapped_sz = 0;
+   }
+   start += pg_size;
+   }
+   if (unmapped_sz) {
+   ret = iommu_map(domain, start, start, unmapped_sz,
+   entry->prot);
if (ret)
goto out;
}
-- 
2.18.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu