Re: [PATCH v2] x86/vm86: Remove deprecated VM86 support

[Ashwin Gundarapu]

Jari,

Thanks for speaking up. Real users matter, and it's good to know someone is still using this.

However, a few points:

1. The Kconfig text itself says VM86 is only "faster than emulation" for performance-sensitive DOS programs. It doesn't say it's required, just faster. Has anyone actually benchmarked the difference recently? DOSEMU's software emulation has improved significantly since VM86 was relevant, and a small performance difference likely doesn't justify keeping 972 lines of kernel code that increases attack surface.

2. The feature is only available on `CONFIG_X86_32`, which has been on life support for years and is already disabled by most distributions. The Kconfig help text (written by Andy Lutomirski and Ingo Molnar) explicitly states that enabling VM86 "adds considerable attack surface to the kernel and slows down system calls and exception handling." The code has seen no real fixes since 2014 — only cleanup patches from people who don't actually use the feature. No one has volunteered to maintain it. And critically: the compromise reached in 2015 was to disable VM86 by default and see if anyone complained. Since then, you're the first person to publicly object to its removal. That strongly suggests the number of active users is extremely small.

3. The x86 maintainers themselves have wanted this gone for years. Back in 2015, Andy Lutomirski called VM86 "a big undocumented mess, it's a real PITA to test, and it looks like a big chunk of vm86_32.c is dead code." He also said: "I find it implausible that vm86_32.c isn't full of root holes. It's also full of hilariously ugly code, it does terrible things to the kernel stack, and its interaction with the syscall slowpath is blatantly incorrect."

   Andy's conclusion was blunt: "No one should be using it anyway. Use DOSBOX or KVM instead."

4. You mentioned keeping VM86 until the year 2038 "32-bit time_t apocalypse." That's 12 years from now. Maintaining legacy code for an extremely small user base for 12 more years is not sustainable. By 2038, 32-bit kernels will be even more dead, and `CONFIG_X86_32` itself may be gone.

5. If you want VM86 to stay in the kernel, are you willing to:
   - Become its official maintainer?
   - Test it on every kernel release?
   - Fix bugs when VM86 inevitably breaks due to core kernel changes?
   - Respond to security reports?

   The kernel needs active maintainers, not passive users.

I'm not against keeping VM86 if someone is actively maintaining it and can prove the performance difference is significant. But if it's just "I use it and hope it doesn't break," that's not a valid reason to keep 972 lines of legacy code that multiple x86 maintainers have called a security risk and a maintenance burden.

Let's see what Thomas, Ingo, Boris, and Dave think.

Regards,
Ashwin Gundarapu


From: Jari Ruusu <jariruusu@xxxxxxxxxxxxxx>
To: "Ashwin Gundarapu"<linuxuser509@xxxxxxxxxxx>
Cc: "tglx"<tglx@xxxxxxxxxx>, "mingo"<mingo@xxxxxxxxxx>, "bp"<bp@xxxxxxxxx>, "hpa"<hpa@xxxxxxxxx>, "x86"<x86@xxxxxxxxxx>, "dave.hansen"<dave.hansen@xxxxxxxxxxxxxxx>, "linux-kernel"<linux-kernel@xxxxxxxxxxxxxxx>
Date: Thu, 28 May 2026 13:19:38 +0530
Subject: Re: [PATCH v2] x86/vm86: Remove deprecated VM86 support

 > Ashwin Gundarapu <linuxuser509@xxxxxxxxxxx> wrote: 
 > > VM86 support allows 16-bit DOS programs to run in virtual 8086 mode 
 > > on 32-bit x86 kernels. This feature has been deprecated and the Kconfig 
 > > help text itself states that any recent software works without it. 
 > > 
 > > Remove the vm86 subsystem entirely including the main driver source, 
 > > Kconfig options, header file, and all references in thread_info, 
 > > processor, and processor-flags headers. 
 > [SNIP] 
 > > -config X86_LEGACY_VM86 
 > > -       bool "Legacy VM86 support" 
 > > -       depends on X86_32 
 > > -       help 
 > > -         This option allows user programs to put the CPU into V8086 
 > > -         mode, which is an 80286-era approximation of 16-bit real mode. 
 > > - 
 > > -         Some very old versions of X and/or vbetool require this option 
 > > -         for user mode setting.  Similarly, DOSEMU will use it if 
 > > -         available to accelerate real mode DOS programs.  However, any 
 >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
 > > -         recent version of DOSEMU, X, or vbetool should be fully 
 > > -         functional even without kernel VM86 support, as they will all 
 > > -         fall back to software emulation. Nevertheless, if you are using 
 > > -         a 16-bit DOS program where 16-bit performance matters, vm86 
 >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
 > > -         mode might be faster than emulation and you might want to 
 > > -         enable this option. 
 >  
 > There are still people using this who need that performance boost. 
 > I am one of those weird ones who still occasionally run real mode 
 > DOS programs under 32-bit x86 Linux + dosemu + FreeDOS. 
 >  
 > I understand that my vote here does not count at all, but my vote is 
 > still to keep X86_LEGACY_VM86 as it is, at least until year-2038 
 > 32-bit x86 time_t apocalypse kicks in, or X86_LEGACY_VM86 turns out 
 > to be a security disaster or unreasonable maintenance burden. 
 >  
 > -- 
 > Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189 
 >  
 >  
 >