Re: [PATCH 3/5] x86, intr-remap: enable interrupt remapping early

[Ingo Molnar]

* Suresh Siddha <suresh.b.siddha@xxxxxxxxx> wrote:

> On Fri, 2009-04-17 at 07:13 -0700, Ingo Molnar wrote:
> > * Weidong Han <weidong.han@xxxxxxxxx> 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:
> 
> I have couple of patches cleaning these up(including some 
> warnings). I will post them shortly.

ok!

> > > +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.
> 
> Typically only on high end platforms we will see x2apic enabled by 
> BIOS before OS handover. And in these cases, BIOS should have 
> already enabled interrupt-remapping in extended interrupt mode, 
> before handing over control to OS. If the extended interrupt mode 
> is set, HW will block the compatibility format interrupts anyway. 
> And I think its better to panic rather than hanging at random 
> places(depending on which interrupts are already in remapped 
> format and which are not). This way, it will be easy for anyone to 
> figure out what is happening.

fair enough.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/