[v10 01/10] iommu: Add new member capability to struct irq_remap_ops
Add a new member 'capability' to struct irq_remap_ops for storing
information about available capabilities such as VT-d
Posted-Interrupts.
Signed-off-by: Feng Wu feng...@intel.com
Reviewed-by: Jiang Liu jiang@linux.intel.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Acked-by: Joerg Roedel j...@8bytes.org
---
arch/x86/include/asm/irq_remapping.h | 4
drivers/iommu/irq_remapping.h| 3 +++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 78974fb..8b432dd 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -29,6 +29,10 @@
struct msi_msg;
struct irq_alloc_info;
+enum irq_remap_cap {
+ IRQ_POSTING_CAP = 0,
+};
+
#ifdef CONFIG_IRQ_REMAP
extern void set_irq_remapping_broken(void);
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index 91d5a11..b6ca30d 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -35,6 +35,9 @@ extern int no_x2apic_optout;
extern int irq_remapping_enabled;
struct irq_remap_ops {
+ /* The supported capabilities */
+ int capability;
+
/* Initializes hardware and makes it ready for remapping interrupts */
int (*prepare)(void);
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 03/10] iommu: dmar: Provide helper to copy shared irte fields
From: Thomas Gleixner t...@linutronix.de
Instead of open coding, provide a helper function to copy the shared
irte fields.
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
include/linux/dmar.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index 0dbcabc..e9bc929 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -249,6 +249,18 @@ struct irte {
};
};
+static inline void dmar_copy_shared_irte(struct irte *dst, struct irte *src)
+{
+ dst-present= src-present;
+ dst-fpd= src-fpd;
+ dst-avail = src-avail;
+ dst-pst= src-pst;
+ dst-vector = src-vector;
+ dst-sid= src-sid;
+ dst-sq = src-sq;
+ dst-svt= src-svt;
+}
+
#define PDA_LOW_BIT26
#define PDA_HIGH_BIT 32
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 00/10] Add VT-d Posted-Interrupts support - IOMMU part
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. With VT-d Posted-Interrupts enabled, external interrupts from direct-assigned devices can be delivered to guests without VMM intervention when guest is running in non-root mode. You can find the VT-d Posted-Interrtups Spec. in the following URL: http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html This series was part of http://thread.gmane.org/gmane.linux.kernel.iommu/7708. To make things clear, send out IOMMU part here. This patch-set is based on the lastest x86/apic branch of tip tree. Divide the whole series which contain multiple components into three parts: - Prerequisite changes to irq subsystem (already merged in tip tree x86/apic branch) - IOMMU part (in this series) - KVM and VFIO parts (will send out this part once the first two parts are accepted) v9-v10: * Fix the build error found by the 0-day test infrastructure. - Define 'enum irq_remap_cap' outside '#ifdef CONFIG_IRQ_REMAP', so we can use it for the paramenter of the dummy function irq_remapping_cap() when CONFIG_IRQ_REMAP is not defined. - Make function irq_remapping_cap() inline when CONFIG_IRQ_REMAP is not defined. v8-v9: * Remove member irte_pi_entry in struct intel_ir_data. * Some changes to the comments. v7-v8: * Save the irq mode (posted or remapped) of an IRTE in struct irq_2_iommu. * Use this new mode to decide whether update the hardware when modifying irte in intel_ir_set_affinity(). v6-v7: * Add an static inline helper function set_irq_posting_cap() to set the PI capability. * Add some comments for the new member ir_data-irte_pi_entry. v5-v6: * Extend 'struct irte' for VT-d Posted-Interrupts, combine remapped and posted mode into one irte structure. v4-v5: * Abstract modify_irte() to accept two format of irte. v3-v4: * Change capability to a int variant flags instead of a function call. * Add hotplug case for VT-d PI. Feng Wu (8): iommu: Add new member capability to struct irq_remap_ops iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip iommu, x86: Save the mode (posted or remapped) of an IRTE iommu, x86: Avoid migrating VT-d posted interrupts iommu, x86: Add cap_pi_support() to detect VT-d PI capability iommu, x86: Setup Posted-Interrupts capability for Intel iommu iommu, x86: Provide irq_remapping_cap() interface iommu, x86: Properly handle posted interrupts for IOMMU hotplug Thomas Gleixner (2): iommu: dmar: Extend struct irte for VT-d Posted-Interrupts iommu: dmar: Provide helper to copy shared irte fields arch/x86/include/asm/irq_remapping.h | 11 + drivers/iommu/intel_irq_remapping.c | 85 +++- drivers/iommu/irq_remapping.c| 11 + drivers/iommu/irq_remapping.h| 6 +++ include/linux/dmar.h | 82 +++--- include/linux/intel-iommu.h | 1 + 6 files changed, 180 insertions(+), 16 deletions(-) -- 2.1.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 08/10] iommu, x86: Setup Posted-Interrupts capability for Intel iommu
Set Posted-Interrupts capability for Intel iommu when Interrupt
Remapping is enabled, clear it when disabled.
Signed-off-by: Feng Wu feng...@intel.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Acked-by: Joerg Roedel j...@8bytes.org
---
drivers/iommu/intel_irq_remapping.c | 30 ++
drivers/iommu/irq_remapping.c | 2 ++
drivers/iommu/irq_remapping.h | 3 +++
3 files changed, 35 insertions(+)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 3bcb459..0f57af7 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -581,6 +581,26 @@ error:
return -ENODEV;
}
+/*
+ * 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_enable_irq_remapping(void)
{
struct dmar_drhd_unit *drhd;
@@ -656,6 +676,8 @@ static int __init intel_enable_irq_remapping(void)
irq_remapping_enabled = 1;
+ set_irq_posting_cap();
+
pr_info(Enabled IRQ remapping in %s mode\n, eim ? x2apic : xapic);
return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
@@ -856,6 +878,12 @@ static void disable_irq_remapping(void)
iommu_disable_irq_remapping(iommu);
}
+
+ /*
+* Clear Posted-Interrupts capability.
+*/
+ if (!disable_irq_post)
+ intel_irq_remap_ops.capability = ~(1 IRQ_POSTING_CAP);
}
static int reenable_irq_remapping(int eim)
@@ -883,6 +911,8 @@ static int reenable_irq_remapping(int eim)
if (!setup)
goto error;
+ set_irq_posting_cap();
+
return 0;
error:
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index fc78b0d..ed605a9 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -22,6 +22,8 @@ int irq_remap_broken;
int disable_sourceid_checking;
int no_x2apic_optout;
+int disable_irq_post = 1;
+
static int disable_irq_remap;
static struct irq_remap_ops *remap_ops;
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index b6ca30d..039c7af 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -34,6 +34,8 @@ extern int disable_sourceid_checking;
extern int no_x2apic_optout;
extern int irq_remapping_enabled;
+extern int disable_irq_post;
+
struct irq_remap_ops {
/* The supported capabilities */
int capability;
@@ -69,6 +71,7 @@ extern void ir_ack_apic_edge(struct irq_data *data);
#define irq_remapping_enabled 0
#define irq_remap_broken 0
+#define disable_irq_post 1
#endif /* CONFIG_IRQ_REMAP */
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 09/10] iommu, x86: Provide irq_remapping_cap() interface
Add a new interface irq_remapping_cap() to detect whether irq
remapping supports new features, such as VT-d Posted-Interrupts.
Export the function, so that KVM code can check this and use this
mechanism properly.
Signed-off-by: Feng Wu feng...@intel.com
Reviewed-by: Jiang Liu jiang@linux.intel.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Acked-by: Joerg Roedel j...@8bytes.org
---
arch/x86/include/asm/irq_remapping.h | 2 ++
drivers/iommu/irq_remapping.c| 9 +
2 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index e479fbd..046c7fb 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -35,6 +35,7 @@ enum irq_remap_cap {
#ifdef CONFIG_IRQ_REMAP
+extern bool irq_remapping_cap(enum irq_remap_cap cap);
extern void set_irq_remapping_broken(void);
extern int irq_remapping_prepare(void);
extern int irq_remapping_enable(void);
@@ -64,6 +65,7 @@ struct vcpu_data {
#else /* CONFIG_IRQ_REMAP */
+static inline bool irq_remapping_cap(enum irq_remap_cap cap) { return 0; }
static inline void set_irq_remapping_broken(void) { }
static inline int irq_remapping_prepare(void) { return -ENODEV; }
static inline int irq_remapping_enable(void) { return -ENODEV; }
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index ed605a9..2d99930 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -81,6 +81,15 @@ void set_irq_remapping_broken(void)
irq_remap_broken = 1;
}
+bool irq_remapping_cap(enum irq_remap_cap cap)
+{
+ if (!remap_ops || disable_irq_post)
+ return 0;
+
+ return (remap_ops-capability (1 cap));
+}
+EXPORT_SYMBOL_GPL(irq_remapping_cap);
+
int __init irq_remapping_prepare(void)
{
if (disable_irq_remap)
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 10/10] iommu, x86: Properly handle posted interrupts for IOMMU hotplug
Return error when inserting a new IOMMU which doesn't support posted
interrupts if posted interrupts are already enabled.
Signed-off-by: Feng Wu feng...@intel.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Acked-by: Joerg Roedel j...@8bytes.org
---
drivers/iommu/intel_irq_remapping.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 0f57af7..80f1d14 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1355,6 +1355,9 @@ int dmar_ir_hotplug(struct dmar_drhd_unit *dmaru, bool
insert)
return -EINVAL;
if (!ecap_ir_support(iommu-ecap))
return 0;
+ if (irq_remapping_cap(IRQ_POSTING_CAP)
+ !cap_pi_support(iommu-cap))
+ return -EBUSY;
if (insert) {
if (!iommu-ir_table)
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 04/10] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip
Interrupt chip callback to set the VCPU affinity for posted interrupts.
[ tglx: Use the helper function to copy from the remap irte instead of
open coding it. Massage the comment as well ]
Signed-off-by: Feng Wu feng...@intel.com
Reviewed-by: Jiang Liu jiang@linux.intel.com
Acked-by: David Woodhouse david.woodho...@intel.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
---
arch/x86/include/asm/irq_remapping.h | 5 +
drivers/iommu/intel_irq_remapping.c | 37
2 files changed, 42 insertions(+)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 8b432dd..e479fbd 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -57,6 +57,11 @@ static inline struct irq_domain
*arch_get_ir_parent_domain(void)
return x86_vector_domain;
}
+struct vcpu_data {
+ u64 pi_desc_addr; /* Physical address of PI Descriptor */
+ u32 vector; /* Guest vector of the interrupt */
+};
+
#else /* CONFIG_IRQ_REMAP */
static inline void set_irq_remapping_broken(void) { }
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 8fad71c..a643eec 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1013,10 +1013,47 @@ static void intel_ir_compose_msi_msg(struct irq_data
*irq_data,
*msg = ir_data-msi_entry;
}
+static int intel_ir_set_vcpu_affinity(struct irq_data *data, void *info)
+{
+ struct intel_ir_data *ir_data = data-chip_data;
+ struct vcpu_data *vcpu_pi_info = info;
+
+ /* stop posting interrupts, back to remapping mode */
+ if (!vcpu_pi_info) {
+ modify_irte(ir_data-irq_2_iommu, ir_data-irte_entry);
+ } else {
+ struct irte irte_pi;
+
+ /*
+* We are not caching the posted interrupt entry. We
+* copy the data from the remapped entry and modify
+* the fields which are relevant for posted mode. The
+* cached remapped entry is used for switching back to
+* remapped mode.
+*/
+ memset(irte_pi, 0, sizeof(irte_pi));
+ dmar_copy_shared_irte(irte_pi, ir_data-irte_entry);
+
+ /* Update the posted mode fields */
+ irte_pi.p_pst = 1;
+ irte_pi.p_urgent = 0;
+ irte_pi.p_vector = vcpu_pi_info-vector;
+ irte_pi.pda_l = (vcpu_pi_info-pi_desc_addr
+ (32 - PDA_LOW_BIT)) ~(-1UL PDA_LOW_BIT);
+ irte_pi.pda_h = (vcpu_pi_info-pi_desc_addr 32)
+ ~(-1UL PDA_HIGH_BIT);
+
+ modify_irte(ir_data-irq_2_iommu, irte_pi);
+ }
+
+ return 0;
+}
+
static struct irq_chip intel_ir_chip = {
.irq_ack = ir_ack_apic_edge,
.irq_set_affinity = intel_ir_set_affinity,
.irq_compose_msi_msg = intel_ir_compose_msi_msg,
+ .irq_set_vcpu_affinity = intel_ir_set_vcpu_affinity,
};
static void intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 05/10] iommu, x86: Save the mode (posted or remapped) of an IRTE
Add a new field to struct irq_2_iommu, which captures whether the
associated IRTE is in posted mode or remapped mode. We update this
field when the IRTE is written into the table.
Suggested-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Feng Wu feng...@intel.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Acked-by: Joerg Roedel j...@8bytes.org
---
drivers/iommu/intel_irq_remapping.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index a643eec..68bce0a 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -18,6 +18,11 @@
#include irq_remapping.h
+enum irq_mode {
+ IRQ_REMAPPING,
+ IRQ_POSTING,
+};
+
struct ioapic_scope {
struct intel_iommu *iommu;
unsigned int id;
@@ -37,6 +42,7 @@ struct irq_2_iommu {
u16 irte_index;
u16 sub_handle;
u8 irte_mask;
+ enum irq_mode mode;
};
struct intel_ir_data {
@@ -104,6 +110,7 @@ static int alloc_irte(struct intel_iommu *iommu, int irq,
irq_iommu-irte_index = index;
irq_iommu-sub_handle = 0;
irq_iommu-irte_mask = mask;
+ irq_iommu-mode = IRQ_REMAPPING;
}
raw_spin_unlock_irqrestore(irq_2_ir_lock, flags);
@@ -144,6 +151,9 @@ static int modify_irte(struct irq_2_iommu *irq_iommu,
__iommu_flush_cache(iommu, irte, sizeof(*irte));
rc = qi_flush_iec(iommu, index, 0);
+
+ /* Update iommu mode according to the IRTE mode */
+ irq_iommu-mode = irte-pst ? IRQ_POSTING : IRQ_REMAPPING;
raw_spin_unlock_irqrestore(irq_2_ir_lock, flags);
return rc;
--
2.1.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 02/10] iommu: dmar: Extend struct irte for VT-d Posted-Interrupts
From: Thomas Gleixner t...@linutronix.de
The IRTE (Interrupt Remapping Table Entry) is either an entry for
remapped or for posted interrupts. The hardware distiguishes between
remapped and posted entries by bit 15 in the low 64 bit of the
IRTE. If cleared the entry is remapped, if set it's posted.
The entries have common fields and dependent on the posted bit fields
with different meanings.
Extend struct irte to handle the differences between remap and posted
mode by having three structs in the unions:
- Shared
- Remapped
- Posted
Signed-off-by: Thomas Gleixner t...@linutronix.de
Acked-by: Joerg Roedel j...@8bytes.org
Signed-off-by: Feng Wu feng...@intel.com
---
include/linux/dmar.h | 70 +---
1 file changed, 55 insertions(+), 15 deletions(-)
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index 8473756..0dbcabc 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -185,33 +185,73 @@ static inline int dmar_device_remove(void *handle)
struct irte {
union {
+ /* Shared between remapped and posted mode*/
struct {
- __u64 present : 1,
- fpd : 1,
- dst_mode: 1,
- redir_hint : 1,
- trigger_mode: 1,
- dlvry_mode : 3,
- avail : 4,
- __reserved_1: 4,
- vector : 8,
- __reserved_2: 8,
- dest_id : 32;
+ __u64 present : 1, /* 0 */
+ fpd : 1, /* 1 */
+ __res0 : 6, /* 2 - 6 */
+ avail : 4, /* 8 - 11 */
+ __res1 : 3, /* 12 - 14 */
+ pst : 1, /* 15 */
+ vector : 8, /* 16 - 23 */
+ __res2 : 40; /* 24 - 63 */
+ };
+
+ /* Remapped mode */
+ struct {
+ __u64 r_present : 1, /* 0 */
+ r_fpd : 1, /* 1 */
+ dst_mode: 1, /* 2 */
+ redir_hint : 1, /* 3 */
+ trigger_mode: 1, /* 4 */
+ dlvry_mode : 3, /* 5 - 7 */
+ r_avail : 4, /* 8 - 11 */
+ r_res0 : 4, /* 12 - 15 */
+ r_vector: 8, /* 16 - 23 */
+ r_res1 : 8, /* 24 - 31 */
+ dest_id : 32; /* 32 - 63 */
+ };
+
+ /* Posted mode */
+ struct {
+ __u64 p_present : 1, /* 0 */
+ p_fpd : 1, /* 1 */
+ p_res0 : 6, /* 2 - 7 */
+ p_avail : 4, /* 8 - 11 */
+ p_res1 : 2, /* 12 - 13 */
+ p_urgent: 1, /* 14 */
+ p_pst : 1, /* 15 */
+ p_vector: 8, /* 16 - 23 */
+ p_res2 : 14, /* 24 - 37 */
+ pda_l : 26; /* 38 - 63 */
};
__u64 low;
};
union {
+ /* Shared between remapped and posted mode*/
struct {
- __u64 sid : 16,
- sq : 2,
- svt : 2,
- __reserved_3: 44;
+ __u64 sid : 16, /* 64 - 79 */
+ sq : 2, /* 80 - 81 */
+ svt : 2, /* 82 - 83 */
+ __res3 : 44; /* 84 - 127 */
+ };
+
+ /* Posted mode*/
+ struct {
+ __u64 p_sid : 16, /* 64 - 79 */
+ p_sq: 2, /* 80 - 81 */
+ p_svt : 2, /* 82 - 83 */
+ p_res3 : 12, /* 84 - 95 */
+ pda_h : 32; /* 96 - 127 */
};
[v10 06/10] iommu, x86: Avoid migrating VT-d posted interrupts
When the interrupt is configured in posted mode, the destination of the interrupt is set in the Posted-Interrupts Descriptor and the migration of these interrupts happens during vCPU scheduling. We still update the cached irte, which will be used when changing back to remapping mode, but we avoid writing the table entry. Signed-off-by: Feng Wu feng...@intel.com Reviewed-by: Jiang Liu jiang@linux.intel.com Acked-by: David Woodhouse david.woodho...@intel.com Reviewed-by: Thomas Gleixner t...@linutronix.de Acked-by: Joerg Roedel j...@8bytes.org --- drivers/iommu/intel_irq_remapping.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index 68bce0a..3bcb459 100644 --- a/drivers/iommu/intel_irq_remapping.c +++ b/drivers/iommu/intel_irq_remapping.c @@ -1003,7 +1003,10 @@ intel_ir_set_affinity(struct irq_data *data, const struct cpumask *mask, */ irte-vector = cfg-vector; irte-dest_id = IRTE_DEST(cfg-dest_apicid); - modify_irte(ir_data-irq_2_iommu, irte); + + /* Update the hardware only if the interrupt is in remapped mode. */ + if (ir_data-irq_2_iommu.mode == IRQ_REMAPPING) + modify_irte(ir_data-irq_2_iommu, irte); /* * After this point, all the interrupts will start arriving -- 2.1.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v10 07/10] iommu, x86: Add cap_pi_support() to detect VT-d PI capability
Add helper function to detect VT-d Posted-Interrupts capability. Signed-off-by: Feng Wu feng...@intel.com Reviewed-by: Jiang Liu jiang@linux.intel.com Acked-by: David Woodhouse david.woodho...@intel.com Reviewed-by: Thomas Gleixner t...@linutronix.de Acked-by: Joerg Roedel j...@8bytes.org --- include/linux/intel-iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h index 0af9b03..0c251be 100644 --- a/include/linux/intel-iommu.h +++ b/include/linux/intel-iommu.h @@ -87,6 +87,7 @@ static inline void dmar_writeq(void __iomem *addr, u64 val) /* * Decoding Capability Register */ +#define cap_pi_support(c) (((c) 59) 1) #define cap_read_drain(c) (((c) 55) 1) #define cap_write_drain(c) (((c) 54) 1) #define cap_max_amask_val(c) (((c) 48) 0x3f) -- 2.1.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/17] Fixes and Cleanups for the Intel VT-d driver
On Mon, Jun 08, 2015 at 04:06:45PM +0800, Li, ZhenHua wrote: Finished testing on my HP huge system, SuperDome X. It works well. Thanks for testing this, Zhen-Hua. Might I add your Tested-by to the patches? Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/17] Fixes and Cleanups for the Intel VT-d driver
My pleasure, thanks. Zhenhua On 06/08/2015 04:23 PM, Joerg Roedel wrote: On Mon, Jun 08, 2015 at 04:06:45PM +0800, Li, ZhenHua wrote: Finished testing on my HP huge system, SuperDome X. It works well. Thanks for testing this, Zhen-Hua. Might I add your Tested-by to the patches? Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
Hello,
On 2015-06-04 15:13, Inki Dae wrote:
On 2015년 06월 04일 22:08, Inki Dae wrote:
On 2015년 06월 03일 17:26, Marek Szyprowski wrote:
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
I have tested this patch series on trats2 board which uses Exynos4412
SoC. However, the booting is halted out. Without iommu, the booting and
display works well.
For this test, I also merged another your patch series in iommu exynos
tree and added device node relevant codes like below,
in exynos4.dtsi file:
fimd: fimd@11c0 {
...
iommus = sysmmu_fimd0;
...
sysmmu_fimd0: sysmmu@11E2 {
compatible = samsung,exynos-sysmmu;
reg = 0x11E2 0x1000;
interrupt-parent = combiner;
interrupts = 5 2;
clock-names = sysmmu, master;
clocks = clock CLK_SMMU_FIMD0, clock CLK_FIMD0;
power-domains = pd_lcd0;
#iommu-cells = 0;
};
in exynos4412-trats2.dts file:
fimd@11c0 {
status = okay;
iommu-reserved-mapping = 0x4000 0x4000 0x4000;
};
Can you check it out?
In addition, sometimes I see below kernel panic logs which means page
fault to fimd occurs while booting:
It looks that you didn't apply patch '[PATCH v7 24/25] ARM: DMA-mapping: add
support for creating reserved mappings in iova space'
(http://thread.gmane.org/gmane.linux.kernel.samsung-soc/45416/focus=45429 ).
There was no consensus on it and it was left unmerged. I will check if it
can be reworked on top of recently introduced iommu default domains feature,
however it would be great if the fixed for FIMD and DRM gets merged earlier,
so the issues in the drivers will no longer be a source of the problem.
[0.394228] 1380.serial: ttySAC0 at MMIO 0x1380 (irq = 56,
base_baud = 0) is a S3C6400/10
[0.394788] 1381.serial: ttySAC1 at MMIO 0x1381 (irq = 57,
base_baud = 0) is a S3C6400/10
[0.395281] 1382.serial: ttySAC2 at MMIO 0x1382 (irq = 58,
base_baud = 0) is a S3C6400/10
[1.122219] console [ttySAC2] enabled
[1.126419] 1383.serial: ttySAC3 at MMIO 0x1383 (irq = 59,
base_baud = 0) is a S3C6400/10
[1.136250] [drm] Initialized drm 1.1.0 20060810
[1.142710] PAGE FAULT occurred at 0x52188000 by 11e2.sysmmu(Page
table base: 0x6ea8)
[1.149754] Lv1 entry: 0x6e92dc01
[1.153172] [ cut here ]
[1.157740] kernel BUG at drivers/iommu/exynos-iommu.c:364!
[1.163296] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[1.169110] Modules linked in:
[1.172154] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-rc4-00563-gee14f4e-dirty #1384
[1.180394] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.186472] task: c06d2df0 ti: c06ce000 task.ti: c06ce000
[1.191861] PC is at exynos_sysmmu_irq+0x184/0x208
[1.196628] LR is at exynos_sysmmu_irq+0xd4/0x208
[1.201316] pc : [c02677cc]lr : [c026771c]psr: 6193
[1.201316] sp : c06cfe90 ip : fp :
[1.212772] r10: c06ff6a3 r9 : 0521 r8 : 52188000
[1.217980] r7 : eea8 r6 : ee9b3428 r5 : ee9b3410 r4 :
[1.224489] r3 : 6e92dc01 r2 : 6e92dc01 r1 : eea55810 r0 : ee9c4e00
[1.231002] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[1.238378] Control: 10c5387d Table: 4000404a DAC: 0015
[1.244107] Process swapper/0 (pid: 0, stack limit = 0xc06ce210)
[1.250096] Stack: (0xc06cfe90 to 0xc06d)
[1.254438] fe80: c06cfe9c
c039caac eef82b80 6ea8
[1.262599] fea0: 16b1580f ee9b4240 ee84ad20
0026 ee84acc0 c0060308
[1.270757] fec0: eef81380 ee84acc0 ee84ad20 ee9b4240
0015 ee804450 c06cff68
[1.278916] fee0: ee808000 c0060400 ee84acc0 ee84ad20 ee807000
c00630a8 0026 c06dddb8
[1.287075] ff00: ee807000 c005f98c 000a c0200ccc 0015
0015
[1.295235] ff20: 0001 c005f98c c06caaac c005fc58 f002000c
0015 c06d07a0 c06cff68
[1.303394] ff40: f002 c06ff6a1 0001 c0009434 c0010068
6113 c06cff9c
[1.311553] ff60: c06cffb8 c0012f40 1288
c001c880 c06ce000 c06d04f8
[1.319712] ff80: c04a1f50 c06c92c4 c06cffb8 c06ff6a1 0001
0100 c06cffb0
[1.327871] ffa0: c0010064 c0010068 6113 c06ce000
c0053f58 c067bc54
[1.336031] ffc0: c067b678
c06a70b8 c07023d4 c06d0480
[1.344190] ffe0: c06a70b4 c06d3f04 4000406a 413fc090
4000807c
[
[GIT PULL] Intel IOMMU fix for 4.1
Linus, please pull from git://git.infradead.org/intel-iommu.git This fixes an oops when attempting to enable 1:1 passthrough mode for devices on which VT-d translation was disabled anyway. It's actually a long-standing bug but recent changes (commit 18436afd) have made it much easier to trigger with 'iommu=pt intel_iommu=igfx_off' on the command line. David Woodhouse (1): iommu/vt-d: Fix passthrough mode with translation-disabled devices drivers/iommu/intel-iommu.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 04/10] iommu/vt-d: functions to copy data from old mem
On Mon, 2015-05-11 at 17:52 +0800, Li, Zhen-Hua wrote:
Add some functions to copy the data from old kernel.
These functions are used to copy context tables and page tables.
To avoid calling iounmap between spin_lock_irqsave and
spin_unlock_irqrestore,
use a link here, store the pointers , and then use iounmap to free
them in
another place.
Li, Zhen-hua:
The functions and logics.
Surely this isn't specific to the Intel IOMMU? Shouldn't it live
elsewhere — either in generic IOMMU code or perhaps in generic kexec
support code?
Don't we need to solve the same kexec problem on *all* platforms with
an IOMMU, and won't they all need something like this?
And I think you're misusing VTD_PAGE_{SHIFT,MASK} when you should be
using the normal PAGE_{SHIFT,MASK}. And shouldn't physical addresses be
phys_addr_t?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[iommu:default-domains 6/22] drivers/iommu/iommu.c:719:8: error: 'struct iommu_group' has no member named 'domain'
tree: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git default-domains head: 4c5de9feccd92ecab4cd5d8ef6d9e0b552e98268 commit: 840136773f5f2e0ed2a6ac671f8635792633c8cf [6/22] iommu: Allocate a default domain for iommu groups config: x86_64-rhel (attached as .config) reproduce: git checkout 840136773f5f2e0ed2a6ac671f8635792633c8cf # save the attached .config to linux build tree make ARCH=x86_64 Note: the iommu/default-domains HEAD 4c5de9feccd92ecab4cd5d8ef6d9e0b552e98268 builds fine. It only hurts bisectibility. All error/warnings (new ones prefixed by ): drivers/iommu/iommu.c: In function 'iommu_group_get_for_pci_dev': drivers/iommu/iommu.c:719:8: error: 'struct iommu_group' has no member named 'domain' group-domain = group-default_domain; ^ vim +719 drivers/iommu/iommu.c 713 /* 714 * Try to allocate a default domain - needs support from the 715 * IOMMU driver. 716 */ 717 group-default_domain = __iommu_domain_alloc(pdev-dev.bus, 718 IOMMU_DOMAIN_DMA); 719 group-domain = group-default_domain; 720 } 721 722 return group; --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.1.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y # CONFIG_NO_HZ_FULL_ALL is not set # CONFIG_NO_HZ_FULL_SYSIDLE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y CONFIG_RCU_USER_QS=y #
Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On Mon, 2015-05-11 at 17:52 +0800, Li, Zhen-Hua wrote: To fix this problem, we modifies the behaviors of the intel vt-d in the crashdump kernel: For DMA Remapping: 1. To accept the vt-d hardware in an active state, 2. Do not disable and re-enable the translation, keep it enabled. 3. Use the old root entry table, do not rewrite the RTA register. 4. Malloc and use new context entry table, copy data from the old ones that used by the old kernel. There are some interesting corner cases to handle here. Firstly, you don't seem to handle the case of extended root/context tables (where ecap_ecs is set). You need to preserve the DMA_RTADDR_RT bit in the Root Table Address register, surely? I think we also need to cope with inheriting page tables from a kernel that *doesn't* use extended page tables, even on hardware that supports it. Which means the use of extended page tables in the new kernel would need to be contingent on something *other* than the pure hardware capabilities. 5. Keep using the old page tables before driver is loaded. 6. After device driver is loaded, when it issues the first dma_map command, free the dmar_domain structure for this device, and generate a new one, so that the device can be assigned a new and empty page table. What if there were RMRRs for this device? Don't we need to ensure that those are present in the new and empty page table when we take it over? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 04/10] iommu/vt-d: functions to copy data from old mem
Hi David,
On Mon, Jun 08, 2015 at 03:15:35PM +0100, David Woodhouse wrote:
Surely this isn't specific to the Intel IOMMU? Shouldn't it live
elsewhere — either in generic IOMMU code or perhaps in generic kexec
support code?
I put a bigger rework of this on-top of Zhen-Hua's patches, you can find
the result in my x86/vt-d branch. With my patches I also removed this
pointer collecting concept and do the iomap_cache and iounmap calls
before the spin-lock is taken, so this problem is now solved
differently.
And I think you're misusing VTD_PAGE_{SHIFT,MASK} when you should be
using the normal PAGE_{SHIFT,MASK}.
I think VT_PAGE_* is correct, since the VT-d driver also runs on ia64.
There the system page-size is different from the VT-d page-size.
And shouldn't physical addresses be phys_addr_t?
This is changed where appropriate, I hope.
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On Mon, Jun 08, 2015 at 03:26:23PM +0100, David Woodhouse wrote: There are some interesting corner cases to handle here. Firstly, you don't seem to handle the case of extended root/context tables (where ecap_ecs is set). You need to preserve the DMA_RTADDR_RT bit in the Root Table Address register, surely? I think we also need to cope with inheriting page tables from a kernel that *doesn't* use extended page tables, even on hardware that supports it. Which means the use of extended page tables in the new kernel would need to be contingent on something *other* than the pure hardware capabilities. Hmm, I also limited this functionality to kdump kernels. Do we still need to preserve these extended data structures even when there is no upstream support for them yet? 5. Keep using the old page tables before driver is loaded. 6. After device driver is loaded, when it issues the first dma_map command, free the dmar_domain structure for this device, and generate a new one, so that the device can be assigned a new and empty page table. What if there were RMRRs for this device? Don't we need to ensure that those are present in the new and empty page table when we take it over? That is still a problem, but not specific to this patch-set. RMRRs will not be restored, because domains allocated out of the DMA-API path will not get any RMRR mappings. This is also a problem with device hotplug (unplug a device with RMRRs and replug it in and the RMRR mappings will be gone). I agree that this needs to be fixed. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 04/10] iommu/vt-d: functions to copy data from old mem
On Mon, 2015-06-08 at 17:21 +0200, Joerg Roedel wrote:
Hi David,
On Mon, Jun 08, 2015 at 03:15:35PM +0100, David Woodhouse wrote:
Surely this isn't specific to the Intel IOMMU? Shouldn't it live
elsewhere — either in generic IOMMU code or perhaps in generic kexec
support code?
I put a bigger rework of this on-top of Zhen-Hua's patches, you can find
the result in my x86/vt-d branch. With my patches I also removed this
pointer collecting concept and do the iomap_cache and iounmap calls
before the spin-lock is taken, so this problem is now solved
differently.
And I think you're misusing VTD_PAGE_{SHIFT,MASK} when you should be
using the normal PAGE_{SHIFT,MASK}.
I think VT_PAGE_* is correct, since the VT-d driver also runs on ia64.
There the system page-size is different from the VT-d page-size.
That's the problem. In __iommu_load_from_oldmem we start with a
physical address in 'from', convert to a VT-d PFN in 'pfn':
+ pfn = from VTD_PAGE_SHIFT;
.. and then proceed to pass that pfn to non-VT-d functions like
page_is_ram() and pfn_to_kaddr() which really need their input pfn
values to be in terms of PAGE_SHIFT not VTD_PAGE_SHIFT.
But it looks like you've completely eliminated that now (including the
page_is_ram check). So although it *was* wrong, it doesn't matter now.
And shouldn't physical addresses be phys_addr_t?
This is changed where appropriate, I hope.
OK. In fact once it's purely internal to intel-iommu.c it doesn't
matter as much since we don't put page tables in high memory on 32-bit
machines.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On Mon, Jun 08, 2015 at 04:50:24PM +0100, David Woodhouse wrote: On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote: Hmm, I also limited this functionality to kdump kernels. Do we still need to preserve these extended data structures even when there is no upstream support for them yet? We *do* have upstream support. The 4.1 kernel will use the extended root/context tables and will set the DMA_RTADDR_RTT bit in the Root Table Address register, even though it doesn't yet actually *use* any of the shiny new bits in the extended context tables. So the code which copies the context tables needs to take that into account. Right, I missed that until now. So what the code with my changes does is, it sets the DMA_RTADDR_RTT bit as it would do on a normal boot. But unlike the root entry table address, this bit can not be changed while translation is active. So I think we need to read out that bit when we find translation enabled and if it is different from what we would set it to, we bail out of any copying, disable translation and proceed as in a normal boot. Yeah. We need the same thing with hardware passthrough — currently I think we refuse to put RMRR-afflicted devices into the passthrough domain purely because we lack the capability to install the RMRR regions if/when we later take it *out* of the hardware passthrough domain. Although I can't quite remember the logic there; surely if it's RMRR-afflicted and we have iommu=pt, it'll *never* be taken out of the 1:1 domain? A device driver might come along and tell us it really is 64-bit capable and thus we might put it *in* to the passthrough domain where previously we'd kept it out... but taking it *out*... ? Well, yeah, the logic is complicated. My hope is to move all that logic to the iommu core code to have it unified between iommu drivers. The way it should work then is basically: Every device (better: iommu-group) has a default domain (which can be a PT domain) and if the device has RMRR mappings, it can not be taken out of that domain. The default-domain branch of my tree contains the beginnings of that, but there is still a lot of work to do to get there. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote: On Mon, Jun 08, 2015 at 03:26:23PM +0100, David Woodhouse wrote: There are some interesting corner cases to handle here. Firstly, you don't seem to handle the case of extended root/context tables (where ecap_ecs is set). You need to preserve the DMA_RTADDR_RT bit in the Root Table Address register, surely? I think we also need to cope with inheriting page tables from a kernel that *doesn't* use extended page tables, even on hardware that supports it. Which means the use of extended page tables in the new kernel would need to be contingent on something *other* than the pure hardware capabilities. Hmm, I also limited this functionality to kdump kernels. Do we still need to preserve these extended data structures even when there is no upstream support for them yet? We *do* have upstream support. The 4.1 kernel will use the extended root/context tables and will set the DMA_RTADDR_RTT bit in the Root Table Address register, even though it doesn't yet actually *use* any of the shiny new bits in the extended context tables. So the code which copies the context tables needs to take that into account. That is still a problem, but not specific to this patch-set. RMRRs will not be restored, because domains allocated out of the DMA-API path will not get any RMRR mappings. This is also a problem with device hotplug (unplug a device with RMRRs and replug it in and the RMRR mappings will be gone). I agree that this needs to be fixed. Yeah. We need the same thing with hardware passthrough — currently I think we refuse to put RMRR-afflicted devices into the passthrough domain purely because we lack the capability to install the RMRR regions if/when we later take it *out* of the hardware passthrough domain. Although I can't quite remember the logic there; surely if it's RMRR-afflicted and we have iommu=pt, it'll *never* be taken out of the 1:1 domain? A device driver might come along and tell us it really is 64-bit capable and thus we might put it *in* to the passthrough domain where previously we'd kept it out... but taking it *out*... ? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
