public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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