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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4ADC3FF3.7010007@redhat.com>
Date:	Mon, 19 Oct 2009 12:31:15 +0200
From:	Stefan Assmann <sassmann@...hat.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	linux-acpi@...r.kernel.org, andi@...stfloor.org,
	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, Jon Masters <jcm@...hat.com>,
	Len Brown <lenb@...nel.org>, tokunaga.keiich@...fujitsu.com,
	Olaf Dabrunz <Olaf.Dabrunz@....net>, greg@...ah.com
Subject: boot interrupts - the next step

Hi all,

boot interrupts are a major pain for linux interrupt handling. I'm not
going into detail here, explaining it all over again. In case you want to
know more refer to the links below.

http://lkml.org/lkml/2009/9/4/350
http://lkml.org/lkml/2008/6/2/269
http://people.redhat.com/sassmann/publications/boot_irq_quirks_rtlws10.pdf
http://people.redhat.com/sassmann/publications/Boot_Interrupts_and_IRQ_Threads.pdf

While we're still fighting this chipset generations boot interrupts
there's something we can do to prevent next gens chipsets from generating
these.

Therefore we need support from BIOS people. In fact ACPI has a method
to "report to the BIOS the current interrupt model used by the OS"¹.
That method is called _PIC. So calling _PIC(1) tells the BIOS the OS has
chosen to run in APIC mode and gives the BIOS the possibility to make
adjustments. Now that is where the BIOS should _disable_ all sources of
boot interrupts.

As the implementation of how to disable boot interrupts is really
chipset specific it's the BIOSes task to disable them in the APIC mode
case. All the boot interrupt quirks we've been adding to the kernel are
just workarounds for buggy BIOSes!

An example of how this can look like, taken from the AMD SB700/710/750
BIOS developers guide²:
During the BIOS POST, the BIOS will do normal PCI IRQ routing through
port C00h/C01h. Once APIC is fully enabled by the OS, the routing in
C00h/C01 must be all cleared to zero. The following is a sample ASL code
that may be incorporated into the BIOS:

         Name(PICF,0x00)
         Method(_PIC, 0x01, NotSerialized)
         {
                 Store (Arg0, PICF)
                 If(Arg0) {
                          \_SB.PCI0.LPC0.DSPI() // clear interrupt at 0xC00/0xC01
                 }
         }
[...] (full implementation snipped)
Note: 0xC00/0xC01 are the PCI interrupt mapping registers in this case.

It's not that hard to do once you're aware of it.
This is a call to all chipset manufacturers/BIOS developers/everyone
involved: Please get the appropriate changes into your BIOS/BIOS
developers guide! Thanks!

¹ ACPI Specification 4.0 (sec 5.8.1)
² http://developer.amd.com/assets/43366_sb7xx_bdg_pub_1.00.pdf (sec 10.5)

  Stefan
--
Stefan Assmann         | Red Hat GmbH
Software Engineer      | Otto-Hahn-Strasse 20, 85609 Dornach
                       | HR: Amtsgericht Muenchen HRB 153243
                       | GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com |     Michael Cunningham, Charles Cachera
--
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