linux-kernel - [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <476524DB.7020806@gmail.com>
Date:	Sun, 16 Dec 2007 14:15:07 +0100
From:	Rene Herman <rene.herman@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Rene Herman <rene.herman@...il.com>, Paul Rolland <rol@...917.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...e.hu>,
	"David P. Reed" <dpreed@...d.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	rol@...be.net
Subject: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

On 16-12-07 00:51, H. Peter Anvin wrote:

> Rene Herman wrote:
>>
>> I hope this is considered half-way correct/sane (note by the way that 
>> it's not a good idea to switch a "native_io_delay_port" value since 
>> plugging in a variable port would clobber register dx for every 
>> outb_p, which would then have to be reloaded for the next outb again). 
>> Comments appreciated.
> 
> That actually wouldn't be that big of a deal.  Switching values in and 
> out of registers is dirt cheap (and MUCH cheaper than an indirect 
> function call)

Well, I suppose. With stuff inline, constantly reloading dx also bloats 
things up a bit but yes, out of line who cares. Do you think this version is 
better?

> Note, however, that your code doesn't deal with io_delay()'s in the boot 
> code (arch/x86/boot) at all, nor (obviously) io_delay()'s in boot 
> loaders.  In the boot code, access to DMI data is NOT available (we 
> can't even use the INT 15h mover if we want to continue to support 
> Loadlin.)
> 
> In the boot code, io_delay() is used to slow down accesses to the KBC, 
> interrupt controller, INT13h logic, and the NMI gate, and to provide a 
> fixed delay during A20 stabilization.

Thanks for the heads up (also saw the SMBIOS update to this) but those don't 
seem to be a problem in fact. David Reed has been running with the simple 
udelay(2) version of this and reported no more hangs. He moreover reported 
no trouble after booting with "acpi=off" meaning that things seem to be fine 
pre-acpi which the boot code (and this io_delay_init) is. So I believe we 
get to ignore those.

David: I've plugged in your DMI values in this. Could you perhaps test this 
to confirm that it works for you?

Any ACKs, NAKs or further comments from others in this thread also welcome.

Changelog in the patch.

  arch/x86/boot/compressed/misc_32.c |    8 ++---
  arch/x86/boot/compressed/misc_64.c |    8 ++---
  arch/x86/kernel/Makefile_32        |    2 -
  arch/x86/kernel/Makefile_64        |    2 -
  arch/x86/kernel/io_delay.c         |   54 
+++++++++++++++++++++++++++++++++++++
  arch/x86/kernel/setup_32.c         |    2 +
  arch/x86/kernel/setup_64.c         |    2 +
  include/asm-x86/io_32.h            |   17 ++---------
  include/asm-x86/io_64.h            |   23 ++++++---------
  9 files changed, 80 insertions(+), 38 deletions(-)

Rene.

View attachment "dmi-io_delay.diff" of type "text/plain" (9859 bytes)