All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: manual merge of the tip tree with the iommu tree
@ 2015-06-17  3:22 Michael Ellerman
  2015-06-17  9:57 ` Joerg Roedel
  0 siblings, 1 reply; 25+ messages in thread
From: Michael Ellerman @ 2015-06-17  3:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: linux-next, linux-kernel@vger.kernel.org Jiang Liu, Joerg Roedel,
	Feng Wu

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();

^ permalink raw reply	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2023-04-03  4:36 Stephen Rothwell
  2023-04-03  5:11 ` Stephen Rothwell
  0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2023-04-03  4:36 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: Dave Hansen, Jacob Pan, Jason Gunthorpe, Jason Gunthorpe,
	Joerg Roedel, Kirill A. Shutemov, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- 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 --]

^ permalink raw reply related	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2022-11-14  4:10 Stephen Rothwell
  0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2022-11-14  4:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: Dave Hansen, Joerg Roedel, Kirill A. Shutemov,
	Linux Kernel Mailing List, Linux Next Mailing List, Lu Baolu

[-- 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 --]

^ permalink raw reply related	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2022-03-07  1:50 Stephen Rothwell
  0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2022-03-07  1:50 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: Borislav Petkov, Fenghua Yu, Joerg Roedel,
	Linux Kernel Mailing List, Linux Next Mailing List, Lu Baolu

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2021-10-21  1:35 Stephen Rothwell
  2021-10-21 15:29 ` Borislav Petkov
  2021-11-02  2:57 ` Stephen Rothwell
  0 siblings, 2 replies; 25+ messages in thread
From: Stephen Rothwell @ 2021-10-21  1:35 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: Borislav Petkov, Fenghua Yu, Linux Kernel Mailing List,
	Linux Next Mailing List, Lu Baolu

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2020-10-02  5:22 Stephen Rothwell
  2020-10-13  3:38 ` Stephen Rothwell
  0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2020-10-02  5:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: Borislav Petkov, Fenghua Yu, Jacob Pan, Jacob Pan, Joerg Roedel,
	Linux Kernel Mailing List, Linux Next Mailing List, Liu Yi L

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2017-08-22  3:50 Stephen Rothwell
  2017-08-22  5:57 ` Baoquan He
                   ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Stephen Rothwell @ 2017-08-22  3:50 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tom Lendacky,
	Baoquan He

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2015-06-09  6:57 Stephen Rothwell
  0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2015-06-09  6:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: linux-next, linux-kernel, Joerg Roedel, Jiang Liu

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* linux-next: manual merge of the tip tree with the iommu tree
@ 2015-06-09  6:57 Stephen Rothwell
  0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2015-06-09  6:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Joerg Roedel
  Cc: linux-next, linux-kernel, Joerg Roedel, Jiang Liu

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
[parent not found: <20150605085030.17051140293@ozlabs.org>]
* linux-next: manual merge of the tip tree with the iommu tree
@ 2011-09-27  5:03 Stephen Rothwell
  0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2011-09-27  5:03 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Ohad Ben-Cohen, David Woodhouse,
	Joerg Roedel, Suresh Siddha

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2023-04-03  5:12 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-17  3:22 linux-next: manual merge of the tip tree with the iommu tree Michael Ellerman
2015-06-17  9:57 ` Joerg Roedel
2015-06-17 21:15   ` Michael Ellerman
  -- strict thread matches above, loose matches on Subject: below --
2023-04-03  4:36 Stephen Rothwell
2023-04-03  5:11 ` Stephen Rothwell
2022-11-14  4:10 Stephen Rothwell
2022-03-07  1:50 Stephen Rothwell
2021-10-21  1:35 Stephen Rothwell
2021-10-21 15:29 ` Borislav Petkov
2021-11-02  2:57 ` Stephen Rothwell
2020-10-02  5:22 Stephen Rothwell
2020-10-13  3:38 ` Stephen Rothwell
2017-08-22  3:50 Stephen Rothwell
2017-08-22  5:57 ` Baoquan He
2017-08-22  7:49   ` Stephen Rothwell
2017-08-22  8:01     ` Baoquan He
2017-08-22  8:43       ` Stephen Rothwell
2017-08-22  8:50         ` Baoquan He
2017-08-22  8:11     ` Baoquan He
2017-08-23 14:15 ` Tom Lendacky
2017-09-04  5:45 ` Stephen Rothwell
2015-06-09  6:57 Stephen Rothwell
2015-06-09  6:57 Stephen Rothwell
     [not found] <20150605085030.17051140293@ozlabs.org>
2015-06-05  8:57 ` Joerg Roedel
2011-09-27  5:03 Stephen Rothwell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.