From: Ingo Molnar <mingo@elte.hu>
To: Weidong Han <weidong.han@intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: dwmw2@infradead.org, allen.m.kay@intel.com, fenghua.yu@intel.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: [PATCH 3/5] x86, intr-remap: enable interrupt remapping early
Date: Fri, 17 Apr 2009 16:13:10 +0200 [thread overview]
Message-ID: <20090417141310.GD23493@elte.hu> (raw)
In-Reply-To: <1239957736-6161-4-git-send-email-weidong.han@intel.com>
* Weidong Han <weidong.han@intel.com> wrote:
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -118,6 +118,8 @@ static int x2apic_preenabled;
> static int disable_x2apic;
> static __init int setup_nox2apic(char *str)
> {
> + if (x2apic_enabled())
> + panic("Bios already enabled x2apic, can't enforce nox2apic");
Could you please turn that into something like:
printk(KERN_WARNING "Bios already enabled x2apic, can't enforce nox2apic");
return 1;
panic-ing the box just because we cannot meet a boot option is not
good.
> +#ifdef CONFIG_X86_X2APIC
> + if (cpu_has_x2apic)
> + ret = enable_intr_remapping(EIM_32BIT_APIC_ID);
> + else
> +#endif
> + ret = enable_intr_remapping(EIM_8BIT_APIC_ID);
That construct looks rather ugly.
Why not clear x2apic from the CPU flags if CONFIG_X86_X2APIC is
disabled. (and print a one-liner during bootup that we did so)
Then this could be written as:
if (cpu_has_x2apic)
ret = enable_intr_remapping(EIM_32BIT_APIC_ID);
else
ret = enable_intr_remapping(EIM_8BIT_APIC_ID);
which looks far more nice.
> +#ifdef CONFIG_X86_X2APIC
> + if (cpu_has_x2apic && !x2apic) {
> x2apic = 1;
> enable_x2apic();
> + pr_info("Enabled x2apic\n");
> }
> +#endif
ditto - this #ifdef could go away with the cpuflags trick.
> +ir_failed:
> + if (x2apic_preenabled)
> + panic("x2apic enabled by bios. But IR enabling failed");
What is the likelyhood that we can continue in compat mode? If
there's some chance, we should rather print a KERN_WARNING and
should try to continue. If IRQs are not coming we'll hang shortly
afterwards anyway.
> panic("x2apic enabled prior OS handover,"
> - " enable CONFIG_INTR_REMAP");
ditto.
> +++ b/drivers/pci/intel-iommu.c
> @@ -1968,15 +1968,6 @@ static int __init init_dmars(void)
> }
> }
>
> -#ifdef CONFIG_INTR_REMAP
> - if (!intr_remapping_enabled) {
> - ret = enable_intr_remapping(0);
> - if (ret)
> - printk(KERN_ERR
> - "IOMMU: enable interrupt remapping failed\n");
> - }
> -#endif
David, is this fine with you? Doing ir-remap setup in the ioapic
code and early on is the obviously right thing to do.
> --- a/drivers/pci/intr_remapping.c
> +++ b/drivers/pci/intr_remapping.c
> @@ -423,20 +423,6 @@ static void iommu_set_intr_remapping(struct intel_iommu *iommu, int mode)
> readl, (sts & DMA_GSTS_IRTPS), sts);
> spin_unlock_irqrestore(&iommu->register_lock, flags);
>
> - if (mode == 0) {
> - spin_lock_irqsave(&iommu->register_lock, flags);
> -
> - /* enable comaptiblity format interrupt pass through */
(this removal also fixes a typo ;-)
> - cmd = iommu->gcmd | DMA_GCMD_CFI;
> - iommu->gcmd |= DMA_GCMD_CFI;
> - writel(cmd, iommu->reg + DMAR_GCMD_REG);
> -
> - IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
> - readl, (sts & DMA_GSTS_CFIS), sts);
> -
> - spin_unlock_irqrestore(&iommu->register_lock, flags);
> - }
Btw., switching on compat mode might be worthwile to do in one of
the failure paths? I.e. we try to switch to IR mode but fail - we
should then try to switch to compat pass-through instead of leaving
the controller in limbo. Does it matter in your opinion?
> -
> /*
> * global invalidation of interrupt entry cache before enabling
> * interrupt-remapping.
> @@ -516,6 +502,20 @@ end:
> spin_unlock_irqrestore(&iommu->register_lock, flags);
> }
>
> +int __init intr_remapping_supported(void)
> +{
> + struct dmar_drhd_unit *drhd;
> +
> + for_each_drhd_unit(drhd) {
> + struct intel_iommu *iommu = drhd->iommu;
> +
> + if (!ecap_ir_support(iommu->ecap))
> + return 0;
> + }
> +
> + return 1;
> +}
Jesse, are these bits fine with you? The layering is still a bit
incestous but it's a marked improvement over what we had there
before.
Ingo
next prev parent reply other threads:[~2009-04-17 14:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 8:42 [PATCH 0/5] fix bugs of x2apic/intr-remap Weidong Han
2009-04-17 8:42 ` [PATCH 1/5] docs: add nox2apic back to kernel-parameters.txt Weidong Han
2009-04-17 13:51 ` Ingo Molnar
2009-04-17 14:48 ` [tip:x86/apic] docs, x86: " tip-bot for Weidong Han
2009-04-18 7:31 ` [tip:x86/urgent] " tip-bot for Weidong Han
2009-04-19 8:24 ` [tip:x86/apic] " tip-bot for Weidong Han
2009-04-17 8:42 ` [PATCH 2/5] x86,intr-remap: fix ack for interrupt remapping Weidong Han
2009-04-17 14:49 ` [tip:x86/apic] x86, intr-remap: " tip-bot for Weidong Han
2009-04-19 8:25 ` tip-bot for Weidong Han
2009-04-17 8:42 ` [PATCH 3/5] x86, intr-remap: enable interrupt remapping early Weidong Han
2009-04-17 14:13 ` Ingo Molnar [this message]
2009-04-17 23:42 ` Suresh Siddha
2009-04-18 7:24 ` Ingo Molnar
2009-04-17 14:49 ` [tip:x86/apic] " tip-bot for Weidong Han
2009-04-19 8:25 ` tip-bot for Weidong Han
2009-04-17 8:42 ` [PATCH 4/5] x86, intr-remap: add option to disable interrupt remapping Weidong Han
2009-04-17 14:49 ` [tip:x86/apic] " tip-bot for Weidong Han
2009-04-19 8:25 ` tip-bot for Weidong Han
2009-04-17 8:42 ` [PATCH 5/5] x86: fix x2apic/intr-remap resume Weidong Han
2009-04-17 14:15 ` Ingo Molnar
2009-04-17 14:49 ` [tip:x86/apic] x86, intr-remap: " tip-bot for Weidong Han
2009-04-19 8:25 ` tip-bot for Weidong Han
2009-04-17 14:30 ` [PATCH 0/5] fix bugs of x2apic/intr-remap Ingo Molnar
2009-04-17 14:41 ` Ingo Molnar
2009-04-18 3:07 ` Han, Weidong
2009-04-18 6:41 ` Ingo Molnar
2009-04-19 6:32 ` David Woodhouse
2009-04-19 8:22 ` Ingo Molnar
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=20090417141310.GD23493@elte.hu \
--to=mingo@elte.hu \
--cc=allen.m.kay@intel.com \
--cc=dwmw2@infradead.org \
--cc=fenghua.yu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=weidong.han@intel.com \
/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