linux-next: manual merge of the tip tree with the iommu tree

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/asm/fpu/api.h

between commit:

  00ecd5401349 ("iommu/vt-d: Clean up unused PASID updating functions")

from the iommu tree and commits:

  a0ff0611c2fb ("x86/fpu: Move KVMs FPU swapping to FPU core")
  ea4d6938d4c0 ("x86/fpu: Replace KVMs home brewed FPU copy from user")
  90489f1dee8b ("x86/fpu: Move fpstate functions to api.h")
  0ae67cc34f76 ("x86/fpu: Remove internal.h dependency from fpu/signal.h")
  6415bb809263 ("x86/fpu: Mop up the internal.h leftovers")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/fpu/api.h
index ca4d0dee1ecd,9263d708dff9..000000000000
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@@ -106,4 -108,34 +108,32 @@@ extern int cpu_has_xfeatures(u64 xfeatu
   */
  #define PASID_DISABLED	0
  
 -static inline void update_pasid(void) { }
 -
+ /* Trap handling */
+ extern int  fpu__exception_code(struct fpu *fpu, int trap_nr);
+ extern void fpu_sync_fpstate(struct fpu *fpu);
+ extern void fpu_reset_from_exception_fixup(void);
+ 
+ /* Boot, hotplug and resume */
+ extern void fpu__init_cpu(void);
+ extern void fpu__init_system(struct cpuinfo_x86 *c);
+ extern void fpu__init_check_bugs(void);
+ extern void fpu__resume_cpu(void);
+ 
+ #ifdef CONFIG_MATH_EMULATION
+ extern void fpstate_init_soft(struct swregs_state *soft);
+ #else
+ static inline void fpstate_init_soft(struct swregs_state *soft) {}
+ #endif
+ 
+ /* State tracking */
+ DECLARE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
+ 
+ /* fpstate-related functions which are exported to KVM */
+ extern void fpu_init_fpstate_user(struct fpu *fpu);
+ 
+ /* KVM specific functions */
+ extern void fpu_swap_kvm_fpu(struct fpu *save, struct fpu *rstor, u64 restore_mask);
+ 
+ extern int fpu_copy_kvm_uabi_to_fpstate(struct fpu *fpu, const void *buf, u64 xcr0, u32 *pkru);
+ 
  #endif /* _ASM_X86_FPU_API_H */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the tip tree with the iommu tree

[Borislav Petkov]

On Thu, Oct 21, 2021 at 12:35:27PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/include/asm/fpu/api.h
> 
> between commit:
> 
>   00ecd5401349 ("iommu/vt-d: Clean up unused PASID updating functions")
> 
> from the iommu tree and commits:
> 
>   a0ff0611c2fb ("x86/fpu: Move KVMs FPU swapping to FPU core")
>   ea4d6938d4c0 ("x86/fpu: Replace KVMs home brewed FPU copy from user")
>   90489f1dee8b ("x86/fpu: Move fpstate functions to api.h")
>   0ae67cc34f76 ("x86/fpu: Remove internal.h dependency from fpu/signal.h")
>   6415bb809263 ("x86/fpu: Mop up the internal.h leftovers")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/include/asm/fpu/api.h
> index ca4d0dee1ecd,9263d708dff9..000000000000
> --- a/arch/x86/include/asm/fpu/api.h
> +++ b/arch/x86/include/asm/fpu/api.h
> @@@ -106,4 -108,34 +108,32 @@@ extern int cpu_has_xfeatures(u64 xfeatu
>    */
>   #define PASID_DISABLED	0
>   
>  -static inline void update_pasid(void) { }
>  -
> + /* Trap handling */
> + extern int  fpu__exception_code(struct fpu *fpu, int trap_nr);
> + extern void fpu_sync_fpstate(struct fpu *fpu);
> + extern void fpu_reset_from_exception_fixup(void);
> + 
> + /* Boot, hotplug and resume */
> + extern void fpu__init_cpu(void);
> + extern void fpu__init_system(struct cpuinfo_x86 *c);
> + extern void fpu__init_check_bugs(void);
> + extern void fpu__resume_cpu(void);
> + 
> + #ifdef CONFIG_MATH_EMULATION
> + extern void fpstate_init_soft(struct swregs_state *soft);
> + #else
> + static inline void fpstate_init_soft(struct swregs_state *soft) {}
> + #endif
> + 
> + /* State tracking */
> + DECLARE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
> + 
> + /* fpstate-related functions which are exported to KVM */
> + extern void fpu_init_fpstate_user(struct fpu *fpu);
> + 
> + /* KVM specific functions */
> + extern void fpu_swap_kvm_fpu(struct fpu *save, struct fpu *rstor, u64 restore_mask);
> + 
> + extern int fpu_copy_kvm_uabi_to_fpstate(struct fpu *fpu, const void *buf, u64 xcr0, u32 *pkru);
> + 
>   #endif /* _ASM_X86_FPU_API_H */

LGTM, thx!

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

Hi all,

On Thu, 21 Oct 2021 12:35:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/include/asm/fpu/api.h
> 
> between commit:
> 
>   00ecd5401349 ("iommu/vt-d: Clean up unused PASID updating functions")
> 
> from the iommu tree and commits:
> 
>   a0ff0611c2fb ("x86/fpu: Move KVMs FPU swapping to FPU core")
>   ea4d6938d4c0 ("x86/fpu: Replace KVMs home brewed FPU copy from user")
>   90489f1dee8b ("x86/fpu: Move fpstate functions to api.h")
>   0ae67cc34f76 ("x86/fpu: Remove internal.h dependency from fpu/signal.h")
>   6415bb809263 ("x86/fpu: Mop up the internal.h leftovers")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc arch/x86/include/asm/fpu/api.h
> index ca4d0dee1ecd,9263d708dff9..000000000000
> --- a/arch/x86/include/asm/fpu/api.h
> +++ b/arch/x86/include/asm/fpu/api.h
> @@@ -106,4 -108,34 +108,32 @@@ extern int cpu_has_xfeatures(u64 xfeatu
>    */
>   #define PASID_DISABLED	0
>   
>  -static inline void update_pasid(void) { }
>  -
> + /* Trap handling */
> + extern int  fpu__exception_code(struct fpu *fpu, int trap_nr);
> + extern void fpu_sync_fpstate(struct fpu *fpu);
> + extern void fpu_reset_from_exception_fixup(void);
> + 
> + /* Boot, hotplug and resume */
> + extern void fpu__init_cpu(void);
> + extern void fpu__init_system(struct cpuinfo_x86 *c);
> + extern void fpu__init_check_bugs(void);
> + extern void fpu__resume_cpu(void);
> + 
> + #ifdef CONFIG_MATH_EMULATION
> + extern void fpstate_init_soft(struct swregs_state *soft);
> + #else
> + static inline void fpstate_init_soft(struct swregs_state *soft) {}
> + #endif
> + 
> + /* State tracking */
> + DECLARE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
> + 
> + /* fpstate-related functions which are exported to KVM */
> + extern void fpu_init_fpstate_user(struct fpu *fpu);
> + 
> + /* KVM specific functions */
> + extern void fpu_swap_kvm_fpu(struct fpu *save, struct fpu *rstor, u64 restore_mask);
> + 
> + extern int fpu_copy_kvm_uabi_to_fpstate(struct fpu *fpu, const void *buf, u64 xcr0, u32 *pkru);
> + 
>   #endif /* _ASM_X86_FPU_API_H */

This is now a conflict between Linus' tree and the iommu tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5496 bytes --]

Hi all,

On Mon, 3 Apr 2023 14:36:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/iommu-sva.c
>   include/linux/sched/mm.h
>   include/linux/ioasid.h
> 
> between commits:
> 
>   cd3891158a77 ("iommu/sva: Move PASID helpers to sva code")
>   4e14176ab13f ("iommu/sva: Stop using ioasid_set for SVA")
>   1a14bf0fc7ed ("iommu/sva: Use GFP_KERNEL for pasid allocation")
> 
> from the iommu tree and commit:
> 
>   400b9b93441c ("iommu/sva: Replace pasid_valid() helper with mm_valid_pasid()")
> 
> from the tip tree.
> 
> I fixed it up (I used the former version of include/linux/sched/mm.h,
> removed include/linux/ioasid.h, updated drivers/iommu/iommu-sva.c
> as below and applied the following patch) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 3 Apr 2023 14:32:58 +1000
> Subject: [PATCH] fixup for "iommu/sva: Replace pasid_valid() helper with mm_valid_pasid()"
> 
> interacting with "iommu/sva: Replace pasid_valid() helper with
> mm_valid_pasid()" and "iommu: Remove ioasid infrastructure"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/iommu.h | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 54f535ff9868..0c5d4c3b59cd 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -1172,16 +1172,15 @@ static inline bool tegra_dev_iommu_get_stream_id(struct device *dev, u32 *stream
>  	return false;
>  }
>  
> -static inline bool pasid_valid(ioasid_t ioasid)
> -{
> -	return ioasid != IOMMU_PASID_INVALID;
> -}
> -
>  #ifdef CONFIG_IOMMU_SVA
>  static inline void mm_pasid_init(struct mm_struct *mm)
>  {
>  	mm->pasid = IOMMU_PASID_INVALID;
>  }
> +static inline bool mm_valid_pasid(struct mm_struct *mm)
> +{
> +	return mm->pasid != IOMMU_PASID_INVALID;
> +}
>  void mm_pasid_drop(struct mm_struct *mm);
>  struct iommu_sva *iommu_sva_bind_device(struct device *dev,
>  					struct mm_struct *mm);
> @@ -1203,6 +1202,7 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
>  	return IOMMU_PASID_INVALID;
>  }
>  static inline void mm_pasid_init(struct mm_struct *mm) {}
> +static inline bool mm_valid_pasid(struct mm_struct *mm) { return false; }
>  static inline void mm_pasid_drop(struct mm_struct *mm) {}
>  #endif /* CONFIG_IOMMU_SVA */
>  
> -- 
> 2.39.2
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iommu/iommu-sva.c
> index c434b95dc8eb,dd76a1a09cf7..000000000000
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@@ -9,14 -10,26 +10,14 @@@
>   #include "iommu-sva.h"
>   
>   static DEFINE_MUTEX(iommu_sva_lock);
>  -static DECLARE_IOASID_SET(iommu_sva_pasid);
>  +static DEFINE_IDA(iommu_global_pasid_ida);
>   
>  -/**
>  - * iommu_sva_alloc_pasid - Allocate a PASID for the mm
>  - * @mm: the mm
>  - * @min: minimum PASID value (inclusive)
>  - * @max: maximum PASID value (inclusive)
>  - *
>  - * Try to allocate a PASID for this mm, or take a reference to the existing one
>  - * provided it fits within the [@min, @max] range. On success the PASID is
>  - * available in mm->pasid and will be available for the lifetime of the mm.
>  - *
>  - * Returns 0 on success and < 0 on error.
>  - */
>  -int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max)
>  +/* Allocate a PASID for the mm within range (inclusive) */
>  +static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max)
>   {
>   	int ret = 0;
>  -	ioasid_t pasid;
>   
> - 	if (!pasid_valid(min) || !pasid_valid(max) ||
>  -	if (min == INVALID_IOASID || max == INVALID_IOASID ||
> ++	if (min == IOMMU_PASID_INVALID || max == IOMMU_PASID_INVALID ||
>   	    min == 0 || max < min)
>   		return -EINVAL;
>   
> @@@ -205,11 -242,3 +209,11 @@@ out_put_mm
>   
>   	return status;
>   }
>  +
>  +void mm_pasid_drop(struct mm_struct *mm)
>  +{
> - 	if (likely(!pasid_valid(mm->pasid)))
> ++	if (likely(!mm_valid_pasid(mm)))
>  +		return;
>  +
>  +	ida_free(&iommu_global_pasid_ida, mm->pasid);
>  +}

It also needs this:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 3 Apr 2023 14:58:05 +1000
Subject: [PATCH] extra fixup for "iommu/sva: Replace pasid_valid() helper with mm_valid_pasid()"

interacting with "iommu/sva: Replace pasid_valid() helper with
mm_valid_pasid()" and "iommu: Remove ioasid infrastructure"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/process_64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 74c7e84a94d8..3bcbc165c5bb 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -39,6 +39,7 @@
 #include <linux/io.h>
 #include <linux/ftrace.h>
 #include <linux/syscalls.h>
+#include <linux/iommu.h>
 
 #include <asm/processor.h>
 #include <asm/pkru.h>
-- 
2.39.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4267 bytes --]

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  drivers/iommu/iommu-sva.c
  include/linux/sched/mm.h
  include/linux/ioasid.h

between commits:

  cd3891158a77 ("iommu/sva: Move PASID helpers to sva code")
  4e14176ab13f ("iommu/sva: Stop using ioasid_set for SVA")
  1a14bf0fc7ed ("iommu/sva: Use GFP_KERNEL for pasid allocation")

from the iommu tree and commit:

  400b9b93441c ("iommu/sva: Replace pasid_valid() helper with mm_valid_pasid()")

from the tip tree.

I fixed it up (I used the former version of include/linux/sched/mm.h,
removed include/linux/ioasid.h, updated drivers/iommu/iommu-sva.c
as below and applied the following patch) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 3 Apr 2023 14:32:58 +1000
Subject: [PATCH] fixup for "iommu/sva: Replace pasid_valid() helper with mm_valid_pasid()"

interacting with "iommu/sva: Replace pasid_valid() helper with
mm_valid_pasid()" and "iommu: Remove ioasid infrastructure"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/iommu.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 54f535ff9868..0c5d4c3b59cd 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1172,16 +1172,15 @@ static inline bool tegra_dev_iommu_get_stream_id(struct device *dev, u32 *stream
 	return false;
 }
 
-static inline bool pasid_valid(ioasid_t ioasid)
-{
-	return ioasid != IOMMU_PASID_INVALID;
-}
-
 #ifdef CONFIG_IOMMU_SVA
 static inline void mm_pasid_init(struct mm_struct *mm)
 {
 	mm->pasid = IOMMU_PASID_INVALID;
 }
+static inline bool mm_valid_pasid(struct mm_struct *mm)
+{
+	return mm->pasid != IOMMU_PASID_INVALID;
+}
 void mm_pasid_drop(struct mm_struct *mm);
 struct iommu_sva *iommu_sva_bind_device(struct device *dev,
 					struct mm_struct *mm);
@@ -1203,6 +1202,7 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
 	return IOMMU_PASID_INVALID;
 }
 static inline void mm_pasid_init(struct mm_struct *mm) {}
+static inline bool mm_valid_pasid(struct mm_struct *mm) { return false; }
 static inline void mm_pasid_drop(struct mm_struct *mm) {}
 #endif /* CONFIG_IOMMU_SVA */
 
-- 
2.39.2

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iommu/iommu-sva.c
index c434b95dc8eb,dd76a1a09cf7..000000000000
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@@ -9,14 -10,26 +10,14 @@@
  #include "iommu-sva.h"
  
  static DEFINE_MUTEX(iommu_sva_lock);
 -static DECLARE_IOASID_SET(iommu_sva_pasid);
 +static DEFINE_IDA(iommu_global_pasid_ida);
  
 -/**
 - * iommu_sva_alloc_pasid - Allocate a PASID for the mm
 - * @mm: the mm
 - * @min: minimum PASID value (inclusive)
 - * @max: maximum PASID value (inclusive)
 - *
 - * Try to allocate a PASID for this mm, or take a reference to the existing one
 - * provided it fits within the [@min, @max] range. On success the PASID is
 - * available in mm->pasid and will be available for the lifetime of the mm.
 - *
 - * Returns 0 on success and < 0 on error.
 - */
 -int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max)
 +/* Allocate a PASID for the mm within range (inclusive) */
 +static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max)
  {
  	int ret = 0;
 -	ioasid_t pasid;
  
- 	if (!pasid_valid(min) || !pasid_valid(max) ||
 -	if (min == INVALID_IOASID || max == INVALID_IOASID ||
++	if (min == IOMMU_PASID_INVALID || max == IOMMU_PASID_INVALID ||
  	    min == 0 || max < min)
  		return -EINVAL;
  
@@@ -205,11 -242,3 +209,11 @@@ out_put_mm
  
  	return status;
  }
 +
 +void mm_pasid_drop(struct mm_struct *mm)
 +{
- 	if (likely(!pasid_valid(mm->pasid)))
++	if (likely(!mm_valid_pasid(mm)))
 +		return;
 +
 +	ida_free(&iommu_global_pasid_ida, mm->pasid);
 +}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/iommu/iommu-sva-lib.c

between commit:

  757636ed2607 ("iommu: Rename iommu-sva-lib.{c,h}")

from the iommu tree and commits:

  e79114b17b81 ("iommu/sva: Replace pasid_valid() helper with mm_valid_pasid()")
  53e220bbaa51 ("x86/mm/iommu/sva: Make LAM and SVA mutually exclusive")

from the tip tree.

The file was renamed in the former, so I deleted it and applied the
following merge resolution patch.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 14 Nov 2022 12:36:45 +1100
Subject: [PATCH] fix up for "iommu: Rename iommu-sva-lib.{c,h}"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/iommu/iommu-sva.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index 24bf9b2b58aa..af05dd9f2a6f 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -2,6 +2,8 @@
 /*
  * Helpers for IOMMU drivers implementing SVA
  */
+#include <linux/mm.h>
+#include <linux/mmu_context.h>
 #include <linux/mutex.h>
 #include <linux/sched/mm.h>
 #include <linux/iommu.h>
@@ -32,21 +34,31 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max)
 	    min == 0 || max < min)
 		return -EINVAL;
 
+	/* Serialize against address tagging enabling */
+	if (mmap_write_lock_killable(mm))
+		return -EINTR;
+
+	if (!arch_pgtable_dma_compat(mm)) {
+		mmap_write_unlock(mm);
+		return -EBUSY;
+	}
+
 	mutex_lock(&iommu_sva_lock);
 	/* Is a PASID already associated with this mm? */
-	if (pasid_valid(mm->pasid)) {
+	if (mm_valid_pasid(mm)) {
 		if (mm->pasid < min || mm->pasid >= max)
 			ret = -EOVERFLOW;
 		goto out;
 	}
 
 	pasid = ioasid_alloc(&iommu_sva_pasid, min, max, mm);
-	if (!pasid_valid(pasid))
+	if (pasid == INVALID_IOASID)
 		ret = -ENOMEM;
 	else
 		mm_pasid_set(mm, pasid);
 out:
 	mutex_unlock(&iommu_sva_lock);
+	mmap_write_unlock(mm);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(iommu_sva_alloc_pasid);
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/iommu/intel/iommu.c

between commit:

  241469685d8d ("iommu/vt-d: Remove aux-domain related callbacks")

from the iommu tree and commit:

  701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit")

from the tip tree.

I fixed it up (I used the former since it removed the functions modified
by the latter) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

Hi all,

On Fri, 2 Oct 2020 15:22:24 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   include/linux/iommu.h
> 
> between commits:
> 
>   23cc3493b5e1 ("iommu/uapi: Rename uapi functions")
>   d90573812eea ("iommu/uapi: Handle data and argsz filled by users")
> 
> from the iommu tree and commit:
> 
>   c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")
> 
> from the tip tree.
> 
> I fixed it up (I used the former version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the iommu tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  include/linux/iommu.h

between commits:

  23cc3493b5e1 ("iommu/uapi: Rename uapi functions")
  d90573812eea ("iommu/uapi: Handle data and argsz filled by users")

from the iommu tree and commit:

  c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")

from the tip tree.

I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 13:50:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/amd_iommu.c
>   drivers/iommu/amd_iommu_init.c
>   drivers/iommu/amd_iommu_proto.h
>   drivers/iommu/amd_iommu_types.h
> 
> between commits:
> 
>   4c232a708be1 ("iommu/amd: Detect pre enabled translation")
>   9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
>   07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
>   daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
> 
> from the iommu tree and commit:
> 
>   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iommu/amd_iommu.c
> index 31bce367866c,4ad7e5e31943..000000000000
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
>   			return -EBUSY;
>   
>   	if (count > 1) {
> - 		__pte = PAGE_SIZE_PTE(phys_addr, page_size);
> + 		__pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
>  -		__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
>  +		__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   	} else
> - 		__pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
>  -		__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
> ++		__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   
>   	if (prot & IOMMU_PROT_IR)
>   		__pte |= IOMMU_PTE_IR;
> diff --cc drivers/iommu/amd_iommu_init.c
> index ff8887ac5555,2292a6cece76..000000000000
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@@ -29,6 -29,8 +29,7 @@@
>   #include <linux/export.h>
>   #include <linux/iommu.h>
>   #include <linux/kmemleak.h>
>  -#include <linux/crash_dump.h>
> + #include <linux/mem_encrypt.h>
>   #include <asm/pci-direct.h>
>   #include <asm/iommu.h>
>   #include <asm/gart.h>
> diff --cc drivers/iommu/amd_iommu_proto.h
> index 90e62e9b01c5,3f12fb2338ea..000000000000
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
>   	return !!(iommu->features & f);
>   }
>   
> + static inline u64 iommu_virt_to_phys(void *vaddr)
> + {
> + 	return (u64)__sme_set(virt_to_phys(vaddr));
> + }
> + 
> + static inline void *iommu_phys_to_virt(unsigned long paddr)
> + {
> + 	return phys_to_virt(__sme_clr(paddr));
> + }
> + 
>  +extern bool translation_pre_enabled(struct amd_iommu *iommu);
>  +extern struct iommu_dev_data *get_dev_data(struct device *dev);
>   #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
> diff --cc drivers/iommu/amd_iommu_types.h
> index 5f775fef341c,8591f43c467c..000000000000
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@@ -361,8 -343,8 +361,8 @@@
>   #define GCR3_VALID		0x01ULL
>   
>   #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
>  -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
>  +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
> - #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
> + #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
>   #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
>   
>   #define IOMMU_PROT_MASK 0x03

Just a reminder that these conflicts still exist.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the tip tree with the iommu tree

[Tom Lendacky]

On 8/21/2017 10:50 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in:
> 
>    drivers/iommu/amd_iommu.c
>    drivers/iommu/amd_iommu_init.c
>    drivers/iommu/amd_iommu_proto.h
>    drivers/iommu/amd_iommu_types.h
> 
> between commits:
> 
>    4c232a708be1 ("iommu/amd: Detect pre enabled translation")
>    9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
>    07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
>    daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
> 
> from the iommu tree and commit:
> 
>    2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Sorry, I was out of the office the past few days.  I checked the
linux-next tree and everything looks good in relation to commit

  2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")

Thanks,
Tom

Re: linux-next: manual merge of the tip tree with the iommu tree

[Baoquan He]

On 08/22/17 at 06:43pm, Stephen Rothwell wrote:
> Hi Baoquan,
> 
> On Tue, 22 Aug 2017 16:01:28 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > On 08/22/17 at 05:49pm, Stephen Rothwell wrote:
> > > Hi Baoquan,
> > > 
> > > On Tue, 22 Aug 2017 13:57:58 +0800 Baoquan He <bhe@redhat.com> wrote:  
> > > >
> > > > On 08/22/17 at 01:50pm, Stephen Rothwell wrote:  
> > > > > from the iommu tree and commit:
> > > > > 
> > > > >   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")    
> > > > 
> > > > Could you tell where the above commit is put? I can have a look.
> > > >   
> > > > > from the tip tree.  
> > >     ^^^^^^^^^^^^^^^^^
> > > 
> > > The tip tree is
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > > 	branch auto-latest  
> > 
> > Thanks, Stephen!
> > 
> > I didn't see the commit 2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to
> > work with memory encryption") in tip/auto-latest branch.
> 
> Its in the copy I fetched this morning (and it has not changed).  the
> auto-latest branch in my tree has commit SHA 87507809e0d7

Later I found it in tip/x86/mm with the git command:
git describe --all --contains [commit-id]

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi Baoquan,

On Tue, 22 Aug 2017 16:01:28 +0800 Baoquan He <bhe@redhat.com> wrote:
>
> On 08/22/17 at 05:49pm, Stephen Rothwell wrote:
> > Hi Baoquan,
> > 
> > On Tue, 22 Aug 2017 13:57:58 +0800 Baoquan He <bhe@redhat.com> wrote:  
> > >
> > > On 08/22/17 at 01:50pm, Stephen Rothwell wrote:  
> > > > from the iommu tree and commit:
> > > > 
> > > >   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")    
> > > 
> > > Could you tell where the above commit is put? I can have a look.
> > >   
> > > > from the tip tree.  
> >     ^^^^^^^^^^^^^^^^^
> > 
> > The tip tree is
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > 	branch auto-latest  
> 
> Thanks, Stephen!
> 
> I didn't see the commit 2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to
> work with memory encryption") in tip/auto-latest branch.

Its in the copy I fetched this morning (and it has not changed).  the
auto-latest branch in my tree has commit SHA 87507809e0d7

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the tip tree with the iommu tree

[Baoquan He]

Hi Stephen,

On 08/22/17 at 05:49pm, Stephen Rothwell wrote:
> Hi Baoquan,
> 
> On Tue, 22 Aug 2017 13:57:58 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > On 08/22/17 at 01:50pm, Stephen Rothwell wrote:
> > > from the iommu tree and commit:
> > > 
> > >   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")  
> > 
> > Could you tell where the above commit is put? I can have a look.
> > 
> > > from the tip tree.
>     ^^^^^^^^^^^^^^^^^
> 
> The tip tree is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> 	branch auto-latest

Thanks a lot!

I have commit 2543a786aa25, not sure which branch it's put in. I tried
to apply it to the current tip/auto-latest, and saw the conflicts. I
think your change is correct. Maybe Joerg can also help have a look.

Thanks
Baoquan

Re: linux-next: manual merge of the tip tree with the iommu tree

[Baoquan He]

On 08/22/17 at 05:49pm, Stephen Rothwell wrote:
> Hi Baoquan,
> 
> On Tue, 22 Aug 2017 13:57:58 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > On 08/22/17 at 01:50pm, Stephen Rothwell wrote:
> > > from the iommu tree and commit:
> > > 
> > >   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")  
> > 
> > Could you tell where the above commit is put? I can have a look.
> > 
> > > from the tip tree.
>     ^^^^^^^^^^^^^^^^^
> 
> The tip tree is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> 	branch auto-latest

Thanks, Stephen!

I didn't see the commit 2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to
work with memory encryption") in tip/auto-latest branch.

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi Baoquan,

On Tue, 22 Aug 2017 13:57:58 +0800 Baoquan He <bhe@redhat.com> wrote:
>
> On 08/22/17 at 01:50pm, Stephen Rothwell wrote:
> > from the iommu tree and commit:
> > 
> >   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")  
> 
> Could you tell where the above commit is put? I can have a look.
> 
> > from the tip tree.
    ^^^^^^^^^^^^^^^^^

The tip tree is

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
	branch auto-latest

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the tip tree with the iommu tree

[Baoquan He]

Hi Stephen,

On 08/22/17 at 01:50pm, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/amd_iommu.c
>   drivers/iommu/amd_iommu_init.c
>   drivers/iommu/amd_iommu_proto.h
>   drivers/iommu/amd_iommu_types.h
> 
> between commits:
> 
>   4c232a708be1 ("iommu/amd: Detect pre enabled translation")
>   9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
>   07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
>   daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
> 
> from the iommu tree and commit:
> 
>   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")

Could you tell where the above commit is put? I can have a look.

Thanks
Baoquan

> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iommu/amd_iommu.c
> index 31bce367866c,4ad7e5e31943..000000000000
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
>   			return -EBUSY;
>   
>   	if (count > 1) {
> - 		__pte = PAGE_SIZE_PTE(phys_addr, page_size);
> + 		__pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
>  -		__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
>  +		__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   	} else
> - 		__pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
>  -		__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
> ++		__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   
>   	if (prot & IOMMU_PROT_IR)
>   		__pte |= IOMMU_PTE_IR;
> diff --cc drivers/iommu/amd_iommu_init.c
> index ff8887ac5555,2292a6cece76..000000000000
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@@ -29,6 -29,8 +29,7 @@@
>   #include <linux/export.h>
>   #include <linux/iommu.h>
>   #include <linux/kmemleak.h>
>  -#include <linux/crash_dump.h>
> + #include <linux/mem_encrypt.h>
>   #include <asm/pci-direct.h>
>   #include <asm/iommu.h>
>   #include <asm/gart.h>
> diff --cc drivers/iommu/amd_iommu_proto.h
> index 90e62e9b01c5,3f12fb2338ea..000000000000
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
>   	return !!(iommu->features & f);
>   }
>   
> + static inline u64 iommu_virt_to_phys(void *vaddr)
> + {
> + 	return (u64)__sme_set(virt_to_phys(vaddr));
> + }
> + 
> + static inline void *iommu_phys_to_virt(unsigned long paddr)
> + {
> + 	return phys_to_virt(__sme_clr(paddr));
> + }
> + 
>  +extern bool translation_pre_enabled(struct amd_iommu *iommu);
>  +extern struct iommu_dev_data *get_dev_data(struct device *dev);
>   #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
> diff --cc drivers/iommu/amd_iommu_types.h
> index 5f775fef341c,8591f43c467c..000000000000
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@@ -361,8 -343,8 +361,8 @@@
>   #define GCR3_VALID		0x01ULL
>   
>   #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
>  -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
>  +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
> - #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
> + #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
>   #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
>   
>   #define IOMMU_PROT_MASK 0x03

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  drivers/iommu/amd_iommu.c
  drivers/iommu/amd_iommu_init.c
  drivers/iommu/amd_iommu_proto.h
  drivers/iommu/amd_iommu_types.h

between commits:

  4c232a708be1 ("iommu/amd: Detect pre enabled translation")
  9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
  07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
  daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")

from the iommu tree and commit:

  2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iommu/amd_iommu.c
index 31bce367866c,4ad7e5e31943..000000000000
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
  			return -EBUSY;
  
  	if (count > 1) {
- 		__pte = PAGE_SIZE_PTE(phys_addr, page_size);
+ 		__pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
 -		__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
 +		__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
  	} else
- 		__pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
 -		__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
++		__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
  
  	if (prot & IOMMU_PROT_IR)
  		__pte |= IOMMU_PTE_IR;
diff --cc drivers/iommu/amd_iommu_init.c
index ff8887ac5555,2292a6cece76..000000000000
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@@ -29,6 -29,8 +29,7 @@@
  #include <linux/export.h>
  #include <linux/iommu.h>
  #include <linux/kmemleak.h>
 -#include <linux/crash_dump.h>
+ #include <linux/mem_encrypt.h>
  #include <asm/pci-direct.h>
  #include <asm/iommu.h>
  #include <asm/gart.h>
diff --cc drivers/iommu/amd_iommu_proto.h
index 90e62e9b01c5,3f12fb2338ea..000000000000
--- a/drivers/iommu/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
  	return !!(iommu->features & f);
  }
  
+ static inline u64 iommu_virt_to_phys(void *vaddr)
+ {
+ 	return (u64)__sme_set(virt_to_phys(vaddr));
+ }
+ 
+ static inline void *iommu_phys_to_virt(unsigned long paddr)
+ {
+ 	return phys_to_virt(__sme_clr(paddr));
+ }
+ 
 +extern bool translation_pre_enabled(struct amd_iommu *iommu);
 +extern struct iommu_dev_data *get_dev_data(struct device *dev);
  #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
diff --cc drivers/iommu/amd_iommu_types.h
index 5f775fef341c,8591f43c467c..000000000000
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@@ -361,8 -343,8 +361,8 @@@
  #define GCR3_VALID		0x01ULL
  
  #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
 -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
 +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
- #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
+ #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
  #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
  
  #define IOMMU_PROT_MASK 0x03

Re: linux-next: manual merge of the tip tree with the iommu tree

[Michael Ellerman]

On Wed, 2015-06-17 at 11:57 +0200, Joerg Roedel wrote:
> Hi Michael,
> 
> On Wed, Jun 17, 2015 at 01:22:54PM +1000, Michael Ellerman wrote:
> > Today's linux-next merge of the tip tree got conflicts in:
> > 
> >   drivers/iommu/intel_irq_remapping.c
> >   drivers/iommu/dmar.c
> > 
> > between commits:
> > 
> >   af3b358e4811 "iommu/vt-d: Copy IR table from old kernel when in kdump mode"
> >   23256d0b3500 "iommu/vt-d: Move EIM detection to intel_prepare_irq_remapping"
> >   9f10e5bf62f7 "iommu/vt-d: Cleanup log messages"
> > 
> > from the iommu tree and commits:
> > 
> >   8dedf4cf5a52 "irq_remapping/vt-d: Change prototypes to prepare for hierarchical irqdomain"
> >   b106ee63abcc "irq_remapping/vt-d: Enhance Intel IR driver to support hierarchical irqdomains"
> >   3d9b98f4ec17 "iommu, x86: Setup Posted-Interrupts capability for Intel iommu"
> >   3c6e567509ed "irq_remapping/vt-d: Clean up unsued code"
> >   34742db8eaf9 "iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit"
> > 
> > from the tip tree.
> > 
> > Or something like that, it was a bit of a mess. Given the size of the conflict
> > I doubt I got it right, but it does seem to build.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> Sorry for the hassle, but your conflict resolution looks good. I tried a
> merge between tip/x86/apic and iommu/next myself and solved the
> conflicts. The results look quite similar to yours (not sure why I got
> conflicts in unrelated files):

Thanks for checking.

cheers

Re: linux-next: manual merge of the tip tree with the iommu tree

[Joerg Roedel]

Hi Michael,

On Wed, Jun 17, 2015 at 01:22:54PM +1000, Michael Ellerman wrote:
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/intel_irq_remapping.c
>   drivers/iommu/dmar.c
> 
> between commits:
> 
>   af3b358e4811 "iommu/vt-d: Copy IR table from old kernel when in kdump mode"
>   23256d0b3500 "iommu/vt-d: Move EIM detection to intel_prepare_irq_remapping"
>   9f10e5bf62f7 "iommu/vt-d: Cleanup log messages"
> 
> from the iommu tree and commits:
> 
>   8dedf4cf5a52 "irq_remapping/vt-d: Change prototypes to prepare for hierarchical irqdomain"
>   b106ee63abcc "irq_remapping/vt-d: Enhance Intel IR driver to support hierarchical irqdomains"
>   3d9b98f4ec17 "iommu, x86: Setup Posted-Interrupts capability for Intel iommu"
>   3c6e567509ed "irq_remapping/vt-d: Clean up unsued code"
>   34742db8eaf9 "iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit"
> 
> from the tip tree.
> 
> Or something like that, it was a bit of a mess. Given the size of the conflict
> I doubt I got it right, but it does seem to build.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Sorry for the hassle, but your conflict resolution looks good. I tried a
merge between tip/x86/apic and iommu/next myself and solved the
conflicts. The results look quite similar to yours (not sure why I got
conflicts in unrelated files):

diff --cc arch/x86/kernel/head_32.S
index 02d2572,53eeb22..544dec4
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@@ -600,10 -603,10 +603,10 @@@ ex_entry
  	pop %ecx
  	pop %eax
  	decl %ss:early_recursion_flag
 -is_nmi:
 +.Lis_nmi:
  	addl $8,%esp		/* drop vector number and error code */
  	iret
- ENDPROC(early_idt_handler)
+ ENDPROC(early_idt_handler_common)
  
  /* This is the default interrupt "handler" :-) */
  	ALIGN
diff --cc arch/x86/kernel/head_64.S
index 43eafc8,df7e780..e5c27f7
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@@ -409,10 -411,10 +411,10 @@@ early_idt_handler_common
  	popq %rcx
  	popq %rax
  	decl early_recursion_flag(%rip)
 -is_nmi:
 +.Lis_nmi:
  	addq $16,%rsp		# drop vector number and error code
  	INTERRUPT_RETURN
- ENDPROC(early_idt_handler)
+ ENDPROC(early_idt_handler_common)
  
  	__INITDATA
  
diff --cc drivers/iommu/dmar.c
index 536f2d8,c588658..c9db04d
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@@ -1642,17 -1642,26 +1642,17 @@@ int dmar_set_interrupt(struct intel_iom
  	if (iommu->irq)
  		return 0;
  
 -	irq = dmar_alloc_hwirq();
 -	if (irq <= 0) {
 +	irq = dmar_alloc_hwirq(iommu->seq_id, iommu->node, iommu);
 +	if (irq > 0) {
 +		iommu->irq = irq;
 +	} else {
- 		pr_err("IOMMU: no free vectors\n");
+ 		pr_err("No free IRQ vectors\n");
  		return -EINVAL;
  	}
  
 -	irq_set_handler_data(irq, iommu);
 -	iommu->irq = irq;
 -
 -	ret = arch_setup_dmar_msi(irq);
 -	if (ret) {
 -		irq_set_handler_data(irq, NULL);
 -		iommu->irq = 0;
 -		dmar_free_hwirq(irq);
 -		return ret;
 -	}
 -
  	ret = request_irq(irq, dmar_fault, IRQF_NO_THREAD, iommu->name, iommu);
  	if (ret)
- 		pr_err("IOMMU: can't request irq\n");
+ 		pr_err("Can't request irq\n");
  	return ret;
  }
  
diff --cc drivers/iommu/intel_irq_remapping.c
index 80f1d14,47fcebf..05375af
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@@ -8,7 -11,7 +11,8 @@@
  #include <linux/irq.h>
  #include <linux/intel-iommu.h>
  #include <linux/acpi.h>
+ #include <linux/crash_dump.h>
 +#include <linux/irqdomain.h>
  #include <asm/io_apic.h>
  #include <asm/smp.h>
  #include <asm/cpu.h>
@@@ -72,14 -54,63 +76,34 @@@ static struct hpet_scope ir_hpet[MAX_HP
   * the dmar_global_lock.
   */
  static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
 +static struct irq_domain_ops intel_ir_domain_ops;
  
+ static void iommu_disable_irq_remapping(struct intel_iommu *iommu);
  static int __init parse_ioapics_under_ir(void);
  
+ static bool ir_pre_enabled(struct intel_iommu *iommu)
+ {
+ 	return (iommu->flags & VTD_FLAG_IRQ_REMAP_PRE_ENABLED);
+ }
+ 
+ static void clear_ir_pre_enabled(struct intel_iommu *iommu)
+ {
+ 	iommu->flags &= ~VTD_FLAG_IRQ_REMAP_PRE_ENABLED;
+ }
+ 
+ static void init_ir_status(struct intel_iommu *iommu)
+ {
+ 	u32 gsts;
+ 
+ 	gsts = readl(iommu->reg + DMAR_GSTS_REG);
+ 	if (gsts & DMA_GSTS_IRES)
+ 		iommu->flags |= VTD_FLAG_IRQ_REMAP_PRE_ENABLED;
+ }
+ 
 -static struct irq_2_iommu *irq_2_iommu(unsigned int irq)
 -{
 -	struct irq_cfg *cfg = irq_cfg(irq);
 -	return cfg ? &cfg->irq_2_iommu : NULL;
 -}
 -
 -static int get_irte(int irq, struct irte *entry)
 -{
 -	struct irq_2_iommu *irq_iommu = irq_2_iommu(irq);
 -	unsigned long flags;
 -	int index;
 -
 -	if (!entry || !irq_iommu)
 -		return -1;
 -
 -	raw_spin_lock_irqsave(&irq_2_ir_lock, flags);
 -
 -	if (unlikely(!irq_iommu->iommu)) {
 -		raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags);
 -		return -1;
 -	}
 -
 -	index = irq_iommu->irte_index + irq_iommu->sub_handle;
 -	*entry = *(irq_iommu->iommu->ir_table->base + index);
 -
 -	raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags);
 -	return 0;
 -}
 -
 -static int alloc_irte(struct intel_iommu *iommu, int irq, u16 count)
 +static int alloc_irte(struct intel_iommu *iommu, int irq,
 +		      struct irq_2_iommu *irq_iommu, u16 count)
  {
  	struct ir_table *table = iommu->ir_table;
 -	struct irq_2_iommu *irq_iommu = irq_2_iommu(irq);
 -	struct irq_cfg *cfg = irq_cfg(irq);
  	unsigned int mask = 0;
  	unsigned long flags;
  	int index;
@@@ -534,9 -693,9 +645,29 @@@ static void __init intel_cleanup_irq_re
  	}
  
  	if (x2apic_supported())
- 		pr_warn("Failed to enable irq remapping.  You are vulnerable to irq-injection attacks.\n");
+ 		pr_warn("Failed to enable irq remapping. You are vulnerable to irq-injection attacks.\n");
+ }
+ 
++/*
++ * Set Posted-Interrupts capability.
++ */
++static inline void set_irq_posting_cap(void)
++{
++	struct dmar_drhd_unit *drhd;
++	struct intel_iommu *iommu;
++
++	if (!disable_irq_post) {
++		intel_irq_remap_ops.capability |= 1 << IRQ_POSTING_CAP;
++
++		for_each_iommu(iommu, drhd)
++			if (!cap_pi_support(iommu->cap)) {
++				intel_irq_remap_ops.capability &=
++						~(1 << IRQ_POSTING_CAP);
++				break;
++			}
++	}
 +}
 +
  static int __init intel_prepare_irq_remapping(void)
  {
  	struct dmar_drhd_unit *drhd;
@@@ -676,11 -784,16 +756,11 @@@ static int __init intel_enable_irq_rema
  
  	irq_remapping_enabled = 1;
  
 -	/*
 -	 * VT-d has a different layout for IO-APIC entries when
 -	 * interrupt remapping is enabled. So it needs a special routine
 -	 * to print IO-APIC entries for debugging purposes too.
 -	 */
 -	x86_io_apic_ops.print_entries = intel_ir_io_apic_print_entries;
 +	set_irq_posting_cap();
  
- 	pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
+ 	pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : "xapic");
  
- 	return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
+ 	return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
  
  error:
  	intel_cleanup_irq_remapping();
diff --cc tools/testing/selftests/x86/Makefile
index 59d364a,9b0d8ba..caa60d5
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@@ -4,9 -4,11 +4,11 @@@ include ../lib.m
  
  .PHONY: all all_32 all_64 warn_32bit_failure clean
  
 -TARGETS_C_BOTHBITS := sigreturn single_step_syscall
 +TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
+ TARGETS_C_32BIT_ONLY := entry_from_vm86
  
- BINARIES_32 := $(TARGETS_C_BOTHBITS:%=%_32)
+ TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
+ BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
  BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
  
  CFLAGS := -O2 -g -std=gnu99 -pthread -Wall

linux-next: manual merge of the tip tree with the iommu tree

[Michael Ellerman]

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  drivers/iommu/intel_irq_remapping.c
  drivers/iommu/dmar.c

between commits:

  af3b358e4811 "iommu/vt-d: Copy IR table from old kernel when in kdump mode"
  23256d0b3500 "iommu/vt-d: Move EIM detection to intel_prepare_irq_remapping"
  9f10e5bf62f7 "iommu/vt-d: Cleanup log messages"

from the iommu tree and commits:

  8dedf4cf5a52 "irq_remapping/vt-d: Change prototypes to prepare for hierarchical irqdomain"
  b106ee63abcc "irq_remapping/vt-d: Enhance Intel IR driver to support hierarchical irqdomains"
  3d9b98f4ec17 "iommu, x86: Setup Posted-Interrupts capability for Intel iommu"
  3c6e567509ed "irq_remapping/vt-d: Clean up unsued code"
  34742db8eaf9 "iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit"

from the tip tree.

Or something like that, it was a bit of a mess. Given the size of the conflict
I doubt I got it right, but it does seem to build.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

cheers


diff --cc drivers/iommu/dmar.c
index c5886582b64f,536f2d8ea41a..000000000000
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@@ -1642,26 -1642,17 +1642,17 @@@ int dmar_set_interrupt(struct intel_iom
  	if (iommu->irq)
  		return 0;
  
- 	irq = dmar_alloc_hwirq();
- 	if (irq <= 0) {
+ 	irq = dmar_alloc_hwirq(iommu->seq_id, iommu->node, iommu);
+ 	if (irq > 0) {
+ 		iommu->irq = irq;
+ 	} else {
 -		pr_err("IOMMU: no free vectors\n");
 +		pr_err("No free IRQ vectors\n");
  		return -EINVAL;
  	}
  
- 	irq_set_handler_data(irq, iommu);
- 	iommu->irq = irq;
- 
- 	ret = arch_setup_dmar_msi(irq);
- 	if (ret) {
- 		irq_set_handler_data(irq, NULL);
- 		iommu->irq = 0;
- 		dmar_free_hwirq(irq);
- 		return ret;
- 	}
- 
  	ret = request_irq(irq, dmar_fault, IRQF_NO_THREAD, iommu->name, iommu);
  	if (ret)
 -		pr_err("IOMMU: can't request irq\n");
 +		pr_err("Can't request irq\n");
  	return ret;
  }
  
diff --cc drivers/iommu/intel_irq_remapping.c
index 47fcebf39e9e,80f1d1486247..000000000000
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@@ -11,7 -8,7 +11,8 @@@
  #include <linux/irq.h>
  #include <linux/intel-iommu.h>
  #include <linux/acpi.h>
 +#include <linux/crash_dump.h>
+ #include <linux/irqdomain.h>
  #include <asm/io_apic.h>
  #include <asm/smp.h>
  #include <asm/cpu.h>
@@@ -54,63 -72,14 +76,34 @@@ static struct hpet_scope ir_hpet[MAX_HP
   * the dmar_global_lock.
   */
  static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
+ static struct irq_domain_ops intel_ir_domain_ops;
  
 +static void iommu_disable_irq_remapping(struct intel_iommu *iommu);
  static int __init parse_ioapics_under_ir(void);
  
 +static bool ir_pre_enabled(struct intel_iommu *iommu)
 +{
 +	return (iommu->flags & VTD_FLAG_IRQ_REMAP_PRE_ENABLED);
 +}
 +
 +static void clear_ir_pre_enabled(struct intel_iommu *iommu)
 +{
 +	iommu->flags &= ~VTD_FLAG_IRQ_REMAP_PRE_ENABLED;
 +}
 +
 +static void init_ir_status(struct intel_iommu *iommu)
 +{
 +	u32 gsts;
 +
 +	gsts = readl(iommu->reg + DMAR_GSTS_REG);
 +	if (gsts & DMA_GSTS_IRES)
 +		iommu->flags |= VTD_FLAG_IRQ_REMAP_PRE_ENABLED;
 +}
 +
- static struct irq_2_iommu *irq_2_iommu(unsigned int irq)
- {
- 	struct irq_cfg *cfg = irq_cfg(irq);
- 	return cfg ? &cfg->irq_2_iommu : NULL;
- }
- 
- static int get_irte(int irq, struct irte *entry)
- {
- 	struct irq_2_iommu *irq_iommu = irq_2_iommu(irq);
- 	unsigned long flags;
- 	int index;
- 
- 	if (!entry || !irq_iommu)
- 		return -1;
- 
- 	raw_spin_lock_irqsave(&irq_2_ir_lock, flags);
- 
- 	if (unlikely(!irq_iommu->iommu)) {
- 		raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags);
- 		return -1;
- 	}
- 
- 	index = irq_iommu->irte_index + irq_iommu->sub_handle;
- 	*entry = *(irq_iommu->iommu->ir_table->base + index);
- 
- 	raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags);
- 	return 0;
- }
- 
- static int alloc_irte(struct intel_iommu *iommu, int irq, u16 count)
+ static int alloc_irte(struct intel_iommu *iommu, int irq,
+ 		      struct irq_2_iommu *irq_iommu, u16 count)
  {
  	struct ir_table *table = iommu->ir_table;
- 	struct irq_2_iommu *irq_iommu = irq_2_iommu(irq);
- 	struct irq_cfg *cfg = irq_cfg(irq);
  	unsigned int mask = 0;
  	unsigned long flags;
  	int index;
@@@ -728,34 -569,10 +680,30 @@@ static int __init intel_prepare_irq_rem
  		if (!ecap_ir_support(iommu->ecap))
  			goto error;
  
 +	/* Detect remapping mode: lapic or x2apic */
 +	if (x2apic_supported()) {
 +		eim = !dmar_x2apic_optout();
 +		if (!eim) {
 +			pr_info("x2apic is disabled because BIOS sets x2apic opt out bit.");
 +			pr_info("Use 'intremap=no_x2apic_optout' to override the BIOS setting.\n");
 +		}
 +	}
 +
 +	for_each_iommu(iommu, drhd) {
 +		if (eim && !ecap_eim_support(iommu->ecap)) {
 +			pr_info("%s does not support EIM\n", iommu->name);
 +			eim = 0;
 +		}
 +	}
 +
 +	eim_mode = eim;
 +	if (eim)
 +		pr_info("Queued invalidation will be enabled to support x2apic and Intr-remapping.\n");
 +
- 	/* Do the initializations early */
- 	for_each_iommu(iommu, drhd) {
- 		if (intel_setup_irq_remapping(iommu)) {
- 			pr_err("Failed to setup irq remapping for %s\n",
- 			       iommu->name);
+ 	/* Do the allocations early */
+ 	for_each_iommu(iommu, drhd)
+ 		if (intel_setup_irq_remapping(iommu))
  			goto error;
- 		}
- 	}
  
  	return 0;
  
@@@ -784,16 -676,11 +752,11 @@@ static int __init intel_enable_irq_rema
  
  	irq_remapping_enabled = 1;
  
- 	/*
- 	 * VT-d has a different layout for IO-APIC entries when
- 	 * interrupt remapping is enabled. So it needs a special routine
- 	 * to print IO-APIC entries for debugging purposes too.
- 	 */
- 	x86_io_apic_ops.print_entries = intel_ir_io_apic_print_entries;
+ 	set_irq_posting_cap();
  
 -	pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
 +	pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : "xapic");
  
 -	return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
 +	return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
  
  error:
  	intel_cleanup_irq_remapping();

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/iommu/dmar.c between commit bc2272dcecae ("iommu/vt-d: Clean up
log messages in intel-iommu.c") from the  tree and commit 34742db8eaf9
("iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit") from
the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/iommu/dmar.c
index a2f50c5f4a2f,536f2d8ea41a..000000000000
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@@ -1642,26 -1642,17 +1642,17 @@@ int dmar_set_interrupt(struct intel_iom
  	if (iommu->irq)
  		return 0;
  
- 	irq = dmar_alloc_hwirq();
- 	if (irq <= 0) {
+ 	irq = dmar_alloc_hwirq(iommu->seq_id, iommu->node, iommu);
+ 	if (irq > 0) {
+ 		iommu->irq = irq;
+ 	} else {
 -		pr_err("IOMMU: no free vectors\n");
 +		pr_err("No free irq vectors\n");
  		return -EINVAL;
  	}
  
- 	irq_set_handler_data(irq, iommu);
- 	iommu->irq = irq;
- 
- 	ret = arch_setup_dmar_msi(irq);
- 	if (ret) {
- 		irq_set_handler_data(irq, NULL);
- 		iommu->irq = 0;
- 		dmar_free_hwirq(irq);
- 		return ret;
- 	}
- 
  	ret = request_irq(irq, dmar_fault, IRQF_NO_THREAD, iommu->name, iommu);
  	if (ret)
 -		pr_err("IOMMU: can't request irq\n");
 +		pr_err("Can't request irq\n");
  	return ret;
  }
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3911 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/iommu/intel_irq_remapping.c between commits 82a09c904f6a
("iommu/vt-d: Load old data structures only in kdump kernel") and
b1e27c302979 ("iommu/vt-d: Move EIM detection to
intel_prepare_irq_remapping") from the iommu tree and commits
b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR driver to support
hierarchical irqdomains") and 84bea5cc7709 ("x86/irq: Remove
x86_io_apic_ops.print_entries and related interfaces") from the tip
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/iommu/intel_irq_remapping.c
index b49aa8cf9d13,8fad71cc27e7..000000000000
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@@ -11,7 -8,7 +11,8 @@@
  #include <linux/irq.h>
  #include <linux/intel-iommu.h>
  #include <linux/acpi.h>
 +#include <linux/crash_dump.h>
+ #include <linux/irqdomain.h>
  #include <asm/io_apic.h>
  #include <asm/smp.h>
  #include <asm/cpu.h>
@@@ -118,9 -98,8 +105,8 @@@ static int alloc_irte(struct intel_iomm
  	index = bitmap_find_free_region(table->bitmap,
  					INTR_REMAP_TABLE_ENTRIES, mask);
  	if (index < 0) {
 -		pr_warn("IR%d: can't allocate an IRTE\n", iommu->seq_id);
 +		pr_warn("Can't allocate an IRTE for IR[%d]\n", iommu->seq_id);
  	} else {
- 		cfg->remapped = 1;
  		irq_iommu->iommu = iommu;
  		irq_iommu->irte_index =  index;
  		irq_iommu->sub_handle = 0;
@@@ -502,10 -413,9 +427,9 @@@ static int intel_setup_irq_remapping(st
  
  	pages = alloc_pages_node(iommu->node, GFP_KERNEL | __GFP_ZERO,
  				 INTR_REMAP_PAGE_ORDER);
- 
  	if (!pages) {
 -		pr_err("IR%d: failed to allocate pages of order %d\n",
 -		       iommu->seq_id, INTR_REMAP_PAGE_ORDER);
 +		pr_err("Failed to allocate pages of order %d for IR[%d]\n",
 +		       INTR_REMAP_PAGE_ORDER, iommu->seq_id);
  		goto out_free_table;
  	}
  
@@@ -519,41 -439,10 +453,43 @@@
  	ir_table->base = page_address(pages);
  	ir_table->bitmap = bitmap;
  	iommu->ir_table = ir_table;
 +
 +	if (!iommu->qi) {
 +		/*
 +		 * Clear previous faults.
 +		 */
 +		dmar_fault(-1, iommu);
 +		dmar_disable_qi(iommu);
 +		if (dmar_enable_qi(iommu)) {
 +			pr_err("Failed to enable queued invalidation\n");
 +			goto out_free_pages;
 +		}
 +	}
 +
 +	iommu_check_pre_ir_status(iommu);
 +
 +	if (!is_kdump_kernel() && iommu->pre_enabled_ir) {
 +		iommu_disable_irq_remapping(iommu);
 +		iommu->pre_enabled_ir = 0;
 +		pr_warn("IRQ remapping was enabled on %s but we are not in kdump mode\n",
 +				iommu->name);
 +	}
 +
 +	if (iommu->pre_enabled_ir) {
 +		if (iommu_load_old_irte(iommu))
 +			pr_err("Failed to copy IR table for %s from previous kernel\n",
 +			       iommu->name);
 +		else
 +			pr_info("Copied IR table for %s from previous kernel\n",
 +				iommu->name);
 +	}
 +
 +	iommu_set_irq_remapping(iommu, eim_mode);
 +
  	return 0;
  
+ out_free_bitmap:
+ 	kfree(bitmap);
  out_free_pages:
  	__free_pages(pages, INTR_REMAP_PAGE_ORDER);
  out_free_table:
@@@ -709,16 -646,9 +653,9 @@@ static int __init intel_enable_irq_rema
  
  	irq_remapping_enabled = 1;
  
- 	/*
- 	 * VT-d has a different layout for IO-APIC entries when
- 	 * interrupt remapping is enabled. So it needs a special routine
- 	 * to print IO-APIC entries for debugging purposes too.
- 	 */
- 	x86_io_apic_ops.print_entries = intel_ir_io_apic_print_entries;
- 
- 	pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : "xapic");
+ 	pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
  
 -	return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
 +	return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
  
  error:
  	intel_cleanup_irq_remapping();

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the tip tree with the iommu tree

[Joerg Roedel]

Hi Michael,

On Fri, Jun 05, 2015 at 06:50:30PM +1000, Michael Ellerman wrote:
> diff --cc include/linux/intel-iommu.h
> index a81ceeeaa3d1,0af9b03e2b1c..000000000000
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@@ -355,9 -349,8 +357,11 @@@ struct intel_iommu 
>   
>   #ifdef CONFIG_IRQ_REMAP
>   	struct ir_table *ir_table;	/* Interrupt remapping info */
> + 	struct irq_domain *ir_domain;
> + 	struct irq_domain *ir_msi_domain;
>  +
>  +	/* whether interrupt remapping is enabled prior to OS*/
>  +	u8		pre_enabled_ir;
>   #endif
>   	struct device	*iommu_dev; /* IOMMU-sysfs device */
>   	int		node;

This solution looks correct, thanks for fixing.


	Joerg

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/iommu/Makefile between commit fcf3a6ef4a58 ("omap: iommu/iovmm:
move to dedicated iommu folder") from the iommu tree and commit
d3f138106b4b ("iommu: Rename the DMAR and INTR_REMAP config options")
from the tip tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/iommu/Makefile
index f798cdd,6394994..0000000
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@@ -1,8 -1,6 +1,9 @@@
  obj-$(CONFIG_IOMMU_API) += iommu.o
  obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o msm_iommu_dev.o
  obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o
- obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o
- obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o
+ obj-$(CONFIG_DMAR_TABLE) += dmar.o
+ obj-$(CONFIG_INTEL_IOMMU) += iova.o intel-iommu.o
+ obj-$(CONFIG_IRQ_REMAP) += intr_remapping.o
 +obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 +obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
 +obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o