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(-)
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
* 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
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
* 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
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
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 :)
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 :) >
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.
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
© 2016 - 2026 Red Hat, Inc.