[PATCH 0/5] x86: Cleanups around slow_down_io()

[PATCH 0/5] x86: Cleanups around slow_down_io()

[Juergen Gross]

While looking at paravirt cleanups I stumbled over slow_down_io() and
the related REALLY_SLOW_IO define.

Especially REALLY_SLOW_IO is a mess, which is proven by 2 completely
wrong use cases.

Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the
io_delay() paravirt function hook.

Patches 2 and 3 are not changing any functionality, but maybe they
should? As the potential bug has been present for more than a decade
now, I went with just deleting the useless "#define REALLY_SLOW_IO".
The alternative would be to do something similar as in patch 5.

Juergen Gross (5):
  x86/paravirt: Replace io_delay() hook with a bool
  hwmon/lm78: Drop REALLY_SLOW_IO setting
  hwmon/w83781d: Drop REALLY_SLOW_IO setting
  block/floppy: Don't use REALLY_SLOW_IO for delays
  x86/io: Remove REALLY_SLOW_IO handling

 arch/x86/include/asm/floppy.h         | 27 ++++++++++++++++++++++-----
 arch/x86/include/asm/io.h             | 12 +++++-------
 arch/x86/include/asm/paravirt.h       | 11 +----------
 arch/x86/include/asm/paravirt_types.h |  3 +--
 arch/x86/kernel/cpu/vmware.c          |  2 +-
 arch/x86/kernel/kvm.c                 |  8 +-------
 arch/x86/kernel/paravirt.c            |  3 +--
 arch/x86/xen/enlighten_pv.c           |  6 +-----
 drivers/block/floppy.c                |  2 --
 drivers/hwmon/lm78.c                  |  5 +++--
 drivers/hwmon/w83781d.c               |  5 +++--
 11 files changed, 39 insertions(+), 45 deletions(-)

-- 
2.51.0

[PATCH 2/5] hwmon/lm78: Drop REALLY_SLOW_IO setting

[Juergen Gross]

In lm78_isa_found() there is REALLY_SLOW_IO defined around some port
accesses, probably in order to wait between multiple accesses.

Unfortunately this isn't making any difference compared to not having
this define since more than a decade, as REALLY_SLOW_IO needs to be
defined while "#include <asm/io.h>" is called to have an effect.

As there seem not to be any outstanding issues in spite of this having
no effect, just drop the "#define" and add a remark to the related
comment.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/hwmon/lm78.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/lm78.c b/drivers/hwmon/lm78.c
index 8b53bb312069..9378a47bf5af 100644
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -843,17 +843,18 @@ static int __init lm78_isa_found(unsigned short address)
 		}
 	}
 
-#define REALLY_SLOW_IO
 	/*
 	 * We need the timeouts for at least some LM78-like
 	 * chips. But only if we read 'undefined' registers.
+	 * There used to be a "#define REALLY_SLOW_IO" to enforce that, but
+	 * this has been without any effect since more than a decade, so it
+	 * has been dropped.
 	 */
 	val = inb_p(address + 1);
 	if (inb_p(address + 2) != val
 	 || inb_p(address + 3) != val
 	 || inb_p(address + 7) != val)
 		goto release;
-#undef REALLY_SLOW_IO
 
 	/*
 	 * We should be able to change the 7 LSB of the address port. The
-- 
2.51.0

Re: [PATCH 2/5] hwmon/lm78: Drop REALLY_SLOW_IO setting

[Guenter Roeck]

On Wed, Nov 26, 2025 at 05:20:15PM +0100, Juergen Gross wrote:
> In lm78_isa_found() there is REALLY_SLOW_IO defined around some port
> accesses, probably in order to wait between multiple accesses.
> 
> Unfortunately this isn't making any difference compared to not having
> this define since more than a decade, as REALLY_SLOW_IO needs to be
> defined while "#include <asm/io.h>" is called to have an effect.
> 
> As there seem not to be any outstanding issues in spite of this having
> no effect, just drop the "#define" and add a remark to the related
> comment.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Applied.

Thanks,
Guenter

[PATCH 3/5] hwmon/w83781d: Drop REALLY_SLOW_IO setting

[Juergen Gross]

In w83781d_isa_found() there is REALLY_SLOW_IO defined around some port
accesses, probably in order to wait between multiple accesses.

Unfortunately this isn't making any difference compared to not having
this define since more than a decade, as REALLY_SLOW_IO needs to be
defined while "#include <asm/io.h>" is called to have an effect.

As there seem not to be any outstanding issues in spite of this having
no effect, just drop the "#define" and add a remark to the related
comment.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/hwmon/w83781d.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index 076200ed2ec9..f664c2152a6d 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -1850,10 +1850,12 @@ w83781d_isa_found(unsigned short address)
 		}
 	}
 
-#define REALLY_SLOW_IO
 	/*
 	 * We need the timeouts for at least some W83781D-like
 	 * chips. But only if we read 'undefined' registers.
+	 * There used to be a "#define REALLY_SLOW_IO" to enforce that, but
+	 * this has been without any effect since more than a decade, so it
+	 * has been dropped.
 	 */
 	val = inb_p(address + 1);
 	if (inb_p(address + 2) != val
@@ -1862,7 +1864,6 @@ w83781d_isa_found(unsigned short address)
 		pr_debug("Detection failed at step %d\n", 1);
 		goto release;
 	}
-#undef REALLY_SLOW_IO
 
 	/*
 	 * We should be able to change the 7 LSB of the address port. The
-- 
2.51.0

Re: [PATCH 3/5] hwmon/w83781d: Drop REALLY_SLOW_IO setting

[Guenter Roeck]

On Wed, Nov 26, 2025 at 05:20:16PM +0100, Juergen Gross wrote:
> In w83781d_isa_found() there is REALLY_SLOW_IO defined around some port
> accesses, probably in order to wait between multiple accesses.
> 
> Unfortunately this isn't making any difference compared to not having
> this define since more than a decade, as REALLY_SLOW_IO needs to be
> defined while "#include <asm/io.h>" is called to have an effect.
> 
> As there seem not to be any outstanding issues in spite of this having
> no effect, just drop the "#define" and add a remark to the related
> comment.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Applied.

Thanks,
Guenter

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[Guenter Roeck]

On 11/26/25 08:20, Juergen Gross wrote:
> While looking at paravirt cleanups I stumbled over slow_down_io() and
> the related REALLY_SLOW_IO define.
> 
> Especially REALLY_SLOW_IO is a mess, which is proven by 2 completely
> wrong use cases.
> 
> Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the
> io_delay() paravirt function hook.
> 
> Patches 2 and 3 are not changing any functionality, but maybe they
> should? As the potential bug has been present for more than a decade
> now, I went with just deleting the useless "#define REALLY_SLOW_IO".
> The alternative would be to do something similar as in patch 5.

Maybe, but as you point out there has not been a report of a problem
for a long time (who knows if any of the affected systems still exist).
We can apply always apply a fix if it turns out that someone does run
into a problem.

Thanks,
Guenter

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[Ingo Molnar]

* Juergen Gross <jgross@suse.com> wrote:

> While looking at paravirt cleanups I stumbled over slow_down_io() and
> the related REALLY_SLOW_IO define.
>
> Especially REALLY_SLOW_IO is a mess, which is proven by 2 completely
> wrong use cases.
>
> Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the
> io_delay() paravirt function hook.
>
> Patches 2 and 3 are not changing any functionality, but maybe they
> should? As the potential bug has been present for more than a decade
> now, I went with just deleting the useless "#define REALLY_SLOW_IO".
> The alternative would be to do something similar as in patch 5.
>
> Juergen Gross (5):
>   x86/paravirt: Replace io_delay() hook with a bool
>   hwmon/lm78: Drop REALLY_SLOW_IO setting
>   hwmon/w83781d: Drop REALLY_SLOW_IO setting
>   block/floppy: Don't use REALLY_SLOW_IO for delays
>   x86/io: Remove REALLY_SLOW_IO handling
>
>  arch/x86/include/asm/floppy.h         | 27 ++++++++++++++++++++++-----
>  arch/x86/include/asm/io.h             | 12 +++++-------
>  arch/x86/include/asm/paravirt.h       | 11 +----------
>  arch/x86/include/asm/paravirt_types.h |  3 +--
>  arch/x86/kernel/cpu/vmware.c          |  2 +-
>  arch/x86/kernel/kvm.c                 |  8 +-------
>  arch/x86/kernel/paravirt.c            |  3 +--
>  arch/x86/xen/enlighten_pv.c           |  6 +-----
>  drivers/block/floppy.c                |  2 --
>  drivers/hwmon/lm78.c                  |  5 +++--
>  drivers/hwmon/w83781d.c               |  5 +++--
>  11 files changed, 39 insertions(+), 45 deletions(-)

I think we should get rid of *all* io_delay hacks, they might have been
relevant in the days of i386 systems, but we don't even support i386
CPUs anymore. Should it cause any regressions, it's easy to bisect to.
There's been enough changes around all these facilities that the
original timings are probably way off already, so we've just been
cargo-cult porting these to newer kernels essentially.

Thanks,

	Ingo

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 2686 bytes --]

On 14.12.25 09:05, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@suse.com> wrote:
> 
>> While looking at paravirt cleanups I stumbled over slow_down_io() and
>> the related REALLY_SLOW_IO define.
>>
>> Especially REALLY_SLOW_IO is a mess, which is proven by 2 completely
>> wrong use cases.
>>
>> Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the
>> io_delay() paravirt function hook.
>>
>> Patches 2 and 3 are not changing any functionality, but maybe they
>> should? As the potential bug has been present for more than a decade
>> now, I went with just deleting the useless "#define REALLY_SLOW_IO".
>> The alternative would be to do something similar as in patch 5.
>>
>> Juergen Gross (5):
>>    x86/paravirt: Replace io_delay() hook with a bool
>>    hwmon/lm78: Drop REALLY_SLOW_IO setting
>>    hwmon/w83781d: Drop REALLY_SLOW_IO setting
>>    block/floppy: Don't use REALLY_SLOW_IO for delays
>>    x86/io: Remove REALLY_SLOW_IO handling
>>
>>   arch/x86/include/asm/floppy.h         | 27 ++++++++++++++++++++++-----
>>   arch/x86/include/asm/io.h             | 12 +++++-------
>>   arch/x86/include/asm/paravirt.h       | 11 +----------
>>   arch/x86/include/asm/paravirt_types.h |  3 +--
>>   arch/x86/kernel/cpu/vmware.c          |  2 +-
>>   arch/x86/kernel/kvm.c                 |  8 +-------
>>   arch/x86/kernel/paravirt.c            |  3 +--
>>   arch/x86/xen/enlighten_pv.c           |  6 +-----
>>   drivers/block/floppy.c                |  2 --
>>   drivers/hwmon/lm78.c                  |  5 +++--
>>   drivers/hwmon/w83781d.c               |  5 +++--
>>   11 files changed, 39 insertions(+), 45 deletions(-)
> 
> I think we should get rid of *all* io_delay hacks, they might have been
> relevant in the days of i386 systems, but we don't even support i386
> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
> There's been enough changes around all these facilities that the
> original timings are probably way off already, so we've just been
> cargo-cult porting these to newer kernels essentially.

Fine with me.

Which path to removal of io_delay would you (and others) prefer?

1. Ripping it out immediately.

2. Hiding it behind a default-off config option for a few kernel versions
    before removing it.

3. Using CONFIG_IO_DELAY_NONE as the default io_delay_type before ripping it
    out.

4. Using CONFIG_IO_DELAY_NONE as the default io_delay_type before hiding it
    behind a default-off config option, then rip it out later.

In cases 2-4 I'd still like to have patch 1 of my series applied, as it will
make paravirt rework easier.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[Ingo Molnar]

* Jürgen Groß <jgross@suse.com> wrote:

> > CPUs anymore. Should it cause any regressions, it's easy to bisect to.
> > There's been enough changes around all these facilities that the
> > original timings are probably way off already, so we've just been
> > cargo-cult porting these to newer kernels essentially.
>
> Fine with me.
>
> Which path to removal of io_delay would you (and others) prefer?
>
> 1. Ripping it out immediately.

I'd just rip it out immediately, and see who complains. :-)

Whatever side effects it still may have, I very strongly doubt it has
anything to do with the original purpose of IO delays...

> In cases 2-4 I'd still like to have patch 1 of my series applied, as it will
> make paravirt rework easier.

Sure.

Thanks,

	Ingo

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 845 bytes --]

On 16.12.25 14:48, Ingo Molnar wrote:
> 
> * Jürgen Groß <jgross@suse.com> wrote:
> 
>>> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
>>> There's been enough changes around all these facilities that the
>>> original timings are probably way off already, so we've just been
>>> cargo-cult porting these to newer kernels essentially.
>>
>> Fine with me.
>>
>> Which path to removal of io_delay would you (and others) prefer?
>>
>> 1. Ripping it out immediately.
> 
> I'd just rip it out immediately, and see who complains. :-)

I figured this might be a little bit too evil. :-)

I've just sent V2 defaulting to have no delay, so anyone hit by that
can still fix it by applying the "io_delay" boot parameter.

I'll do the ripping out for kernel 6.21 (or whatever it will be called).


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[H. Peter Anvin]

On December 16, 2025 5:55:54 AM PST, "Jürgen Groß" <jgross@suse.com> wrote:
>On 16.12.25 14:48, Ingo Molnar wrote:
>> 
>> * Jürgen Groß <jgross@suse.com> wrote:
>> 
>>>> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
>>>> There's been enough changes around all these facilities that the
>>>> original timings are probably way off already, so we've just been
>>>> cargo-cult porting these to newer kernels essentially.
>>> 
>>> Fine with me.
>>> 
>>> Which path to removal of io_delay would you (and others) prefer?
>>> 
>>> 1. Ripping it out immediately.
>> 
>> I'd just rip it out immediately, and see who complains. :-)
>
>I figured this might be a little bit too evil. :-)
>
>I've just sent V2 defaulting to have no delay, so anyone hit by that
>can still fix it by applying the "io_delay" boot parameter.
>
>I'll do the ripping out for kernel 6.21 (or whatever it will be called).
>
>
>Juergen

Ok, I'm going to veto ripping it out from the real-mode init code, because I actually know why it is there :) ... and that code is pre-UEFI legacy these days anyway.

Other places... I don't care :)

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[David Laight]

On Tue, 16 Dec 2025 07:32:09 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On December 16, 2025 5:55:54 AM PST, "Jürgen Groß" <jgross@suse.com> wrote:
> >On 16.12.25 14:48, Ingo Molnar wrote:  
> >> 
> >> * Jürgen Groß <jgross@suse.com> wrote:
> >>   
> >>>> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
> >>>> There's been enough changes around all these facilities that the
> >>>> original timings are probably way off already, so we've just been
> >>>> cargo-cult porting these to newer kernels essentially.  
> >>> 
> >>> Fine with me.
> >>> 
> >>> Which path to removal of io_delay would you (and others) prefer?
> >>> 
> >>> 1. Ripping it out immediately.  
> >> 
> >> I'd just rip it out immediately, and see who complains. :-)  
> >
> >I figured this might be a little bit too evil. :-)
> >
> >I've just sent V2 defaulting to have no delay, so anyone hit by that
> >can still fix it by applying the "io_delay" boot parameter.
> >
> >I'll do the ripping out for kernel 6.21 (or whatever it will be called).
> >
> >
> >Juergen  
> 
> Ok, I'm going to veto ripping it out from the real-mode init code,
> because I actually know why it is there :) ...

Pray tell.
One thing I can think of is the delay allows time for a level-sensitive
IRQ line to de-assert before an ISR exits.
Or, maybe more obscure, to avoid back to back accesses to some register
breaking the 'inter-cycle recovery time' for the device.
That was a good way to 'break' the Zilog SCC and the 8259 interrupt
controller (eg on any reference board with a '286 cpu).

	David

> and that code is pre-UEFI legacy these days anyway.
> 
> Other places... I don't care :)
> 

Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[H. Peter Anvin]

On December 16, 2025 11:59:12 AM PST, David Laight <david.laight.linux@gmail.com> wrote:
>On Tue, 16 Dec 2025 07:32:09 -0800
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> On December 16, 2025 5:55:54 AM PST, "Jürgen Groß" <jgross@suse.com> wrote:
>> >On 16.12.25 14:48, Ingo Molnar wrote:  
>> >> 
>> >> * Jürgen Groß <jgross@suse.com> wrote:
>> >>   
>> >>>> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
>> >>>> There's been enough changes around all these facilities that the
>> >>>> original timings are probably way off already, so we've just been
>> >>>> cargo-cult porting these to newer kernels essentially.  
>> >>> 
>> >>> Fine with me.
>> >>> 
>> >>> Which path to removal of io_delay would you (and others) prefer?
>> >>> 
>> >>> 1. Ripping it out immediately.  
>> >> 
>> >> I'd just rip it out immediately, and see who complains. :-)  
>> >
>> >I figured this might be a little bit too evil. :-)
>> >
>> >I've just sent V2 defaulting to have no delay, so anyone hit by that
>> >can still fix it by applying the "io_delay" boot parameter.
>> >
>> >I'll do the ripping out for kernel 6.21 (or whatever it will be called).
>> >
>> >
>> >Juergen  
>> 
>> Ok, I'm going to veto ripping it out from the real-mode init code,
>> because I actually know why it is there :) ...
>
>Pray tell.
>One thing I can think of is the delay allows time for a level-sensitive
>IRQ line to de-assert before an ISR exits.
>Or, maybe more obscure, to avoid back to back accesses to some register
>breaking the 'inter-cycle recovery time' for the device.
>That was a good way to 'break' the Zilog SCC and the 8259 interrupt
>controller (eg on any reference board with a '286 cpu).
>
>	David
>
>> and that code is pre-UEFI legacy these days anyway.
>> 
>> Other places... I don't care :)
>> 
>
>

A20 gate logic on some motherboards, especially.