| Message ID | 20231112041643.2868316-13-jacob.jun.pan@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Coalesced Interrupt Delivery with posted MSI | expand |
On Sat, Nov 11 2023 at 20:16, Jacob Pan wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > When programming IRTE for posted mode, we need to retrieve the > physical we need .... I surely did not write this changelog. > address of the posted interrupt descriptor (PID) that belongs to it's > target CPU. > > This per CPU PID has already been set up during cpu_init(). This information is useful because? > +static u64 get_pi_desc_addr(struct irq_data *irqd) > +{ > + int cpu = cpumask_first(irq_data_get_effective_affinity_mask(irqd)); The effective affinity mask is magically correct when this is called?
Hi Thomas, On Wed, 06 Dec 2023 21:19:11 +0100, Thomas Gleixner <tglx@linutronix.de> wrote: > On Sat, Nov 11 2023 at 20:16, Jacob Pan wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > > > When programming IRTE for posted mode, we need to retrieve the > > physical > > we need .... I surely did not write this changelog. > Will delete this. > > address of the posted interrupt descriptor (PID) that belongs to it's > > target CPU. > > > > This per CPU PID has already been set up during cpu_init(). > > This information is useful because? ditto. > > +static u64 get_pi_desc_addr(struct irq_data *irqd) > > +{ > > + int cpu = > > cpumask_first(irq_data_get_effective_affinity_mask(irqd)); > > The effective affinity mask is magically correct when this is called? > My understanding is that remappable device MSIs have the following hierarchy,e.g. parent: domain: INTEL-IR-5-13 hwirq: 0x20000 chip: INTEL-IR-POST flags: 0x0 parent: domain: VECTOR hwirq: 0x3c chip: APIC When irqs are allocated and activated, parents domain op is always called first. Effective affinity mask is set up by the parent domain, i.e. VECTOR. Example call stack for alloc: irq_data_update_effective_affinity apic_update_irq_cfg x86_vector_alloc_irqs intel_irq_remapping_alloc msi_domain_alloc x86_vector_activate also changes the effective affinity mask before calling intel_irq_remapping_activate() where a posted interrupt is configured for its destination CPU. At runtime, when IRQ affinity is changed by userspace Intel interrupt remapping code also calls parent data/chip to update the effective affinity map before changing IRTE. intel_ir_set_affinity(struct irq_data *data, const struct cpumask *mask, bool force) { ret = parent->chip->irq_set_affinity(parent, mask, force); ... } Here the parent APIC chip does apic_set_affinity() which will set up effective mask before posted MSI affinity change. Maybe I missed some cases? I will also add a check if the effective affinity mask is not set up. static phys_addr_t get_pi_desc_addr(struct irq_data *irqd) { int cpu = cpumask_first(irq_data_get_effective_affinity_mask(irqd)); if (WARN_ON(cpu >= nr_cpu_ids)) return 0; return __pa(per_cpu_ptr(&posted_interrupt_desc, cpu)); } Thanks, Jacob
On Fri, Jan 26 2024 at 15:30, Jacob Pan wrote: > On Wed, 06 Dec 2023 21:19:11 +0100, Thomas Gleixner <tglx@linutronix.de> > wrote: >> > +static u64 get_pi_desc_addr(struct irq_data *irqd) >> > +{ >> > + int cpu = >> > cpumask_first(irq_data_get_effective_affinity_mask(irqd)); >> >> The effective affinity mask is magically correct when this is called? >> > My understanding is that remappable device MSIs have the following > hierarchy,e.g. SNIP > Here the parent APIC chip does apic_set_affinity() which will set up > effective mask before posted MSI affinity change. > > Maybe I missed some cases? The function is only used in intel_ir_reconfigure_irte_posted() in the next patch, but it's generally available. So I asked that question because if it's called in some other context then it's going to be not guaranteed. That also begs the question why this function exists in the first place. This really can be part of intel_ir_reconfigure_irte_posted(), which makes it clear what the context is, no? Thanks, tglx
Hi Thomas, On Tue, 13 Feb 2024 09:21:47 +0100, Thomas Gleixner <tglx@linutronix.de> wrote: > > Here the parent APIC chip does apic_set_affinity() which will set up > > effective mask before posted MSI affinity change. > > > > Maybe I missed some cases? > > The function is only used in intel_ir_reconfigure_irte_posted() in the > next patch, but it's generally available. So I asked that question > because if it's called in some other context then it's going to be not > guaranteed. > > That also begs the question why this function exists in the first > place. This really can be part of intel_ir_reconfigure_irte_posted(), > which makes it clear what the context is, no? Make sense, will fold it in next time. Thanks, Jacob
diff --git a/drivers/iommu/intel/irq_remapping.c b/drivers/iommu/intel/irq_remapping.c index f2870d3c8313..971e6c37002f 100644 --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -1125,6 +1125,15 @@ struct irq_remap_ops intel_irq_remap_ops = { .reenable = reenable_irq_remapping, .enable_faulting = enable_drhd_fault_handling, }; +#ifdef CONFIG_X86_POSTED_MSI + +static u64 get_pi_desc_addr(struct irq_data *irqd) +{ + int cpu = cpumask_first(irq_data_get_effective_affinity_mask(irqd)); + + return __pa(per_cpu_ptr(&posted_interrupt_desc, cpu)); +} +#endif static void intel_ir_reconfigure_irte(struct irq_data *irqd, bool force) {