From: Thomas Gleixner <tglx@linutronix.de>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
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, 01 Mar 2024 20:59:22 +0100 [thread overview]
Message-ID: <87msrhwwo5.ffs@tglx> (raw)
In-Reply-To: <20240301115000.4ba2e411@jacob-builder>
Jacob!
On Fri, Mar 01 2024 at 11:50, Jacob Pan wrote:
> On Thu, 29 Feb 2024 23:18:37 +0100, Thomas Gleixner <tglx@linutronix.de>
> wrote:
>> On Thu, Feb 29 2024 at 14:07, Dimitri Sivanich wrote:
>> 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?
Both interrupt remap and the IOMMU use DMAR and both set the DMAR's
fault interrupt up, whatever comes first. If IR is enabled then IR does
it, if not then the IOMMU init handles it.
But yes, the interrupt is part of DMAR.
> Maybe we should not call it irq_remap_work, call it dmar_fault_irq_work
> instead?
This work thing does not work at all as I explained in detail. No matter
how you name it. The only sane way to do that is with a hotplug state.
Thanks,
tglx
next prev parent reply other threads:[~2024-03-01 19:59 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
2024-03-01 19:59 ` Thomas Gleixner [this message]
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=87msrhwwo5.ffs@tglx \
--to=tglx@linutronix.de \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@linux.intel.com \
--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=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