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

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