[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 1/5] x86/paravirt: Replace io_delay() hook with a bool

[Juergen Gross]

The io_delay() paravirt hook is in no way performance critical and all
users setting it to a different function than native_io_delay() are
using an empty function as replacement.

This enables to replace the hook with a bool indicating whether
native_io_delay() should be called.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/io.h             |  7 +++++--
 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 +-----
 7 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index ca309a3227c7..0448575569b9 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -245,9 +245,14 @@ extern void io_delay_init(void);
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>
 #else
+#define call_io_delay() true
+#endif
 
 static inline void slow_down_io(void)
 {
+	if (!call_io_delay())
+		return;
+
 	native_io_delay();
 #ifdef REALLY_SLOW_IO
 	native_io_delay();
@@ -256,8 +261,6 @@ static inline void slow_down_io(void)
 #endif
 }
 
-#endif
-
 #define BUILDIO(bwl, type)						\
 static inline void out##bwl##_p(type value, u16 port)			\
 {									\
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index b5e59a7ba0d0..0ab798d234cc 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -53,16 +53,7 @@ static inline u64 paravirt_steal_clock(int cpu)
 void __init paravirt_set_cap(void);
 #endif
 
-/* The paravirtualized I/O functions */
-static inline void slow_down_io(void)
-{
-	PVOP_VCALL0(cpu.io_delay);
-#ifdef REALLY_SLOW_IO
-	PVOP_VCALL0(cpu.io_delay);
-	PVOP_VCALL0(cpu.io_delay);
-	PVOP_VCALL0(cpu.io_delay);
-#endif
-}
+#define call_io_delay() pv_info.io_delay
 
 void native_flush_tlb_local(void);
 void native_flush_tlb_global(void);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 37a8627d8277..ee399f467796 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -36,6 +36,7 @@ struct pv_info {
 #ifdef CONFIG_PARAVIRT_XXL
 	u16 extra_user_64bit_cs;  /* __USER_CS if none */
 #endif
+	bool io_delay;
 
 	const char *name;
 };
@@ -51,8 +52,6 @@ struct pv_lazy_ops {
 
 struct pv_cpu_ops {
 	/* hooks for various privileged instructions */
-	void (*io_delay)(void);
-
 #ifdef CONFIG_PARAVIRT_XXL
 	unsigned long (*get_debugreg)(int regno);
 	void (*set_debugreg)(int regno, unsigned long value);
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index cb3f900c46fc..47db25d63c8d 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -338,7 +338,7 @@ arch_initcall(activate_jump_labels);
 static void __init vmware_paravirt_ops_setup(void)
 {
 	pv_info.name = "VMware hypervisor";
-	pv_ops.cpu.io_delay = paravirt_nop;
+	pv_info.io_delay = false;
 
 	if (vmware_tsc_khz == 0)
 		return;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b67d7c59dca0..b02d441efa3b 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -73,12 +73,6 @@ DEFINE_PER_CPU_DECRYPTED(struct kvm_steal_time, steal_time) __aligned(64) __visi
 static int has_steal_clock = 0;
 
 static int has_guest_poll = 0;
-/*
- * No need for any "IO delay" on KVM
- */
-static void kvm_io_delay(void)
-{
-}
 
 #define KVM_TASK_SLEEP_HASHBITS 8
 #define KVM_TASK_SLEEP_HASHSIZE (1<<KVM_TASK_SLEEP_HASHBITS)
@@ -312,7 +306,7 @@ static void __init paravirt_ops_setup(void)
 	pv_info.name = "KVM";
 
 	if (kvm_para_has_feature(KVM_FEATURE_NOP_IO_DELAY))
-		pv_ops.cpu.io_delay = kvm_io_delay;
+		pv_info.io_delay = false;
 
 #ifdef CONFIG_X86_IO_APIC
 	no_timer_check = 1;
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index ab3e172dcc69..8ee952e7e7d4 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -113,6 +113,7 @@ struct pv_info pv_info = {
 #ifdef CONFIG_PARAVIRT_XXL
 	.extra_user_64bit_cs = __USER_CS,
 #endif
+	.io_delay = true,
 };
 
 /* 64-bit pagetable entries */
@@ -120,8 +121,6 @@ struct pv_info pv_info = {
 
 struct paravirt_patch_template pv_ops = {
 	/* Cpu ops. */
-	.cpu.io_delay		= native_io_delay,
-
 #ifdef CONFIG_PARAVIRT_XXL
 	.cpu.cpuid		= native_cpuid,
 	.cpu.get_debugreg	= pv_native_get_debugreg,
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4806cc28d7ca..a43b525f25cd 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1046,10 +1046,6 @@ static void xen_update_io_bitmap(void)
 }
 #endif
 
-static void xen_io_delay(void)
-{
-}
-
 static DEFINE_PER_CPU(unsigned long, xen_cr0_value);
 
 static unsigned long xen_read_cr0(void)
@@ -1209,6 +1205,7 @@ void __init xen_setup_vcpu_info_placement(void)
 
 static const struct pv_info xen_info __initconst = {
 	.extra_user_64bit_cs = FLAT_USER_CS64,
+	.io_delay = false,
 	.name = "Xen",
 };
 
@@ -1253,7 +1250,6 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = {
 		.invalidate_io_bitmap = xen_invalidate_io_bitmap,
 		.update_io_bitmap = xen_update_io_bitmap,
 #endif
-		.io_delay = xen_io_delay,
 
 		.start_context_switch = xen_start_context_switch,
 		.end_context_switch = xen_end_context_switch,
-- 
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.