When will x86 cpu drop supporting old instructions and generate an exception instead ?

[William Gaatjes]

I have been reading about the vme bug ryzen has for virtual 8086 mode.
Is this even used today in modern software ?
Does the bios still use it ?
It seems to me this is not used anymore because it is unsafe.

https://en.wikipedia.org/wiki/Virtual_8086_mode#Virtual_8086_mode_enhancements_.28VME.29

Would it now not be time to create a cpu that would just throw an exception when such instructions or processor modes are executed. And offer the instruction complete with all relevant flags and address to the os to handle it to do a software emulation ? Even virtual machines could be build this way.
Modern x86 cpus are fast enough for this option.

 

[whm1974]

I think the BIOS still uses it as well as FreeDOS. But I could be wrong.

 

[jpiniero]

There's been rumors about Saphhire Rapids doing some breakage.

 

[wildhorse2k]

Here is a good description of the Ryzen VME bug and what it causes http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

 

[NTMBK]

Never. Backwards compatibility is far more valuable than the <1% improvement you'd get from dropping support.

 

[SarahKerrigan]

Breaking DOS support would be a bad thing for Intel's remaining embedded user base.

I'm sure DMP Electronics would approve very strongly of Intel doing it, though.

 

[William Gaatjes]

Here is a good description of the Ryzen VME bug and what it causes http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

Aha, ok.
When using x86-64bit. One would never know or encouter the bug unless a Virtual machine is used and old code like windows xp or dos is executed. And 16 bit code is run. And the VME bit is enabled.
I still have a windows xp virtual machine. But i do not know if i use 16 bit coded programs at all...
For modern 64bit software it is not an issue. For old 16bit legacy software it is.

 

[jpiniero]

Never. Backwards compatibility is far more valuable than the <1% improvement you'd get from dropping support.

I honestly have no idea about improvement but I imagine that there's some amount of testing and validation that would need to be done (testing that AMD obviously in this case didn't do).

 

[William Gaatjes]

I honestly have no idea about improvement but I imagine that there's some amount of testing and validation that would need to be done (testing that AMD obviously in this case didn't do).

We will just have to wait if it can be fixed.
If i understand the article correctly, with the VME flag disabled, virtual machines and the software would still run fine.
There is a workaround.

How did AMD miss it? Because only 32-bit OSes are affected, and only when running 16-bit real-mode code. Except with Windows XP and Server 2003 it’s much worse and these systems may not even boot.

To be clear, the problem is not at all specific to virtualization. It has been confirmed on a Ryzen 5 1500X running FreeDOS—which comes with the JemmEx memory manager, which enables VME by default. Until VME was disabled, any attempt to boot with JemmEx failed with invalid opcode exceptions. After disabling VME, FreeDOS worked normally.

That is not surprising because when the problematic INT instruction is executed inside a VM using AMD-V, it is almost always executed without any intervention from the hypervisor, which means the hypervisor has no opportunity to mess anything up.

The workaround is simple—if possible, mask out the VME CPUID bit (bit 1 in register EDX of leaf 1), which is something hypervisors typically allow. Windows does not require VME and without VME, XP can be booted normally on Ryzen CPUs, at least in a VM.