From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Dimitri Sivanich <sivanich@hpe.com>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Steve Wahl <steve.wahl@hpe.com>,
Russ Anderson <russ.anderson@hpe.com>,
jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH] Allocate DMAR fault interrupts locally
Date: Fri, 1 Mar 2024 11:50:00 -0800 [thread overview]
Message-ID: <20240301115000.4ba2e411@jacob-builder> (raw)
In-Reply-To: <87plwe7w3m.ffs@tglx>
Hi Thomas,
On Thu, 29 Feb 2024 23:18:37 +0100, Thomas Gleixner <tglx@linutronix.de>
wrote:
> Dimitri!
>
> On Thu, Feb 29 2024 at 14:07, Dimitri Sivanich wrote:
>
> The subject lacks a subsystem prefix. You're doing this for how many
> decades now?
>
> > The Intel IOMMU code currently tries to allocate all DMAR fault
> > interrupt
> > +#ifdef CONFIG_X86_LOCAL_APIC
>
> I seriously doubt that this code can ever be compiled w/o X86_LOCAL_APIC:
>
> obj-$(CONFIG_DMAR_TABLE) += dmar.o
>
> config DMAR_TABLE
> bool
>
> config INTEL_IOMMU
> depends on PCI_MSI && ACPI && X86
> select DMAR_TABLE
>
> config IRQ_REMAP
> depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
> select DMAR_TABLE
>
> config X86_LOCAL_APIC
> def_bool y
> depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC ||
> PCI_MSI
>
> What are you trying to achieve here other than #ifdef voodoo?
>
> > +static void __init irq_remap_enable_fault_handling_thr(struct
> > work_struct *work) +{
> > + irq_remap_enable_fault_handling();
>
> because if INTEL_IOMMU=y and IRQ_REMAP=n then X86_LOCAL_APIC=y and this
> muck gets invoked for nothing. 'git grep irq_remap_enable_fault_handling
> include/' might give you a hint.
>
> > +}
> > +
> > +static int __init assign_dmar_vectors(void)
> > +{
> > + struct work_struct irq_remap_work;
> > + int nid;
> > +
> > + INIT_WORK(&irq_remap_work,
> > irq_remap_enable_fault_handling_thr);
> > + cpus_read_lock();
> > + for_each_online_node(nid) {
> > + /* Boot cpu dmar vectors are assigned before the rest
> > */
> > + if (nid == cpu_to_node(get_boot_cpu_id()))
> > + continue;
> > + schedule_work_on(cpumask_first(cpumask_of_node(nid)),
> > + &irq_remap_work);
> > + flush_work(&irq_remap_work);
> > + }
> > + cpus_read_unlock();
> > + return 0;
> > +}
> > +
> > +arch_initcall(assign_dmar_vectors);
>
> Stray newline before arch_initcall(), but that's not the problem.
>
> The real problems are:
>
> 1) This approach only works when _ALL_ APs have been brought up during
> boot. With 'maxcpus=N' on the command line this will fail to enable
> fault handling when the APs which have not been brought up initially
> are onlined later on.
>
> This might be working in practice because intel_iommu_init() will
> enable the interrupts later on via init_dmars() unconditionally, but
> that's far from correct because IRQ_REMAP does not depend on
> INTEL_IOMMU.
The dmar fault interrupt is VT-d's own interrupt, not subject to IRQ_REMAP.
So this set up has nothing to do with IR, right?
Maybe we should not call it irq_remap_work, call it dmar_fault_irq_work
instead?
> 2) It leaves a gap where the reporting is not working between bringing
> up the APs during boot and this initcall. Mostly theoretical, but
> that does not make it more correct either.
>
> What you really want is a cpu hotplug state in the CPUHP_BP_PREPARE_DYN
> space which enables the interrupt for the node _before_ the first AP of
> the node is brought up. That will solve the problem nicely w/o any of
> the above issues.
>
> Thanks,
>
> tglx
>
Thanks,
Jacob
next prev parent reply other threads:[~2024-03-01 19:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 20:07 [PATCH] Allocate DMAR fault interrupts locally Dimitri Sivanich
2024-02-29 22:18 ` Thomas Gleixner
2024-03-01 19:50 ` Jacob Pan [this message]
2024-03-01 19:59 ` Thomas Gleixner
2024-03-11 20:38 ` Dimitri Sivanich
2024-03-21 22:13 ` Jacob Pan
2024-03-24 21:05 ` Thomas Gleixner
2024-03-25 18:56 ` Jacob Pan
2024-04-04 0:00 ` Jacob Pan
2024-03-24 20:05 ` Thomas Gleixner
2024-03-25 12:20 ` Dimitri Sivanich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240301115000.4ba2e411@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=russ.anderson@hpe.com \
--cc=sivanich@hpe.com \
--cc=steve.wahl@hpe.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox