All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.