lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 17 Apr 2009 16:42:23 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Han, Weidong" <weidong.han@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"Kay, Allen M" <allen.m.kay@...el.com>,
	"Yu, Fenghua" <fenghua.yu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: Re: [PATCH 3/5] x86, intr-remap: enable interrupt remapping early

On Fri, 2009-04-17 at 07:13 -0700, Ingo Molnar wrote:
> * Weidong Han <weidong.han@...el.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:

I have couple of patches cleaning these up(including some warnings). I
will post them shortly.

> > +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.

thanks,
suresh

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ