[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 4/5] block/floppy: Don't use REALLY_SLOW_IO for delays

[Juergen Gross]

Instead of defining REALLY_SLOW_IO before including io.h, add the
required additional calls of native_io_delay() to the related functions
in arch/x86/include/asm/floppy.h.

This will remove the last place where REALLY_SLOW_IO is being defined.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/floppy.h | 27 ++++++++++++++++++++++-----
 drivers/block/floppy.c        |  2 --
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
index e7a244051c62..8d1e86687b98 100644
--- a/arch/x86/include/asm/floppy.h
+++ b/arch/x86/include/asm/floppy.h
@@ -29,9 +29,6 @@
 #define CSW fd_routine[can_use_virtual_dma & 1]
 
 
-#define fd_inb(base, reg)		inb_p((base) + (reg))
-#define fd_outb(value, base, reg)	outb_p(value, (base) + (reg))
-
 #define fd_request_dma()	CSW._request_dma(FLOPPY_DMA, "floppy")
 #define fd_free_dma()		CSW._free_dma(FLOPPY_DMA)
 #define fd_enable_irq()		enable_irq(FLOPPY_IRQ)
@@ -49,6 +46,26 @@ static char *virtual_dma_addr;
 static int virtual_dma_mode;
 static int doing_pdma;
 
+static inline u8 fd_inb(u16 base, u16 reg)
+{
+	u8 ret = inb_p(base + reg);
+
+	native_io_delay();
+	native_io_delay();
+	native_io_delay();
+
+	return ret;
+}
+
+static inline void fd_outb(u8 value, u16 base, u16 reg)
+{
+	outb_p(value, base + reg);
+
+	native_io_delay();
+	native_io_delay();
+	native_io_delay();
+}
+
 static irqreturn_t floppy_hardint(int irq, void *dev_id)
 {
 	unsigned char st;
@@ -79,9 +96,9 @@ static irqreturn_t floppy_hardint(int irq, void *dev_id)
 			if (st != (STATUS_DMA | STATUS_READY))
 				break;
 			if (virtual_dma_mode)
-				outb_p(*lptr, virtual_dma_port + FD_DATA);
+				fd_outb(*lptr, virtual_dma_port, FD_DATA);
 			else
-				*lptr = inb_p(virtual_dma_port + FD_DATA);
+				*lptr = fd_inb(virtual_dma_port, FD_DATA);
 		}
 		virtual_dma_count = lcount;
 		virtual_dma_addr = lptr;
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 5336c3c5ca36..cda36a8f9a05 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -145,8 +145,6 @@
  * Better audit of register_blkdev.
  */
 
-#define REALLY_SLOW_IO
-
 #define DEBUGT 2
 
 #define DPRINT(format, args...) \
-- 
2.51.0

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.