VMware Communities
SanAndreasEleva
Enthusiast
Enthusiast

How do I mask out VME on AMD Ryzen 7 1700 for Windows 16-bit/32-bit hybrid VMs (Windows 98)?

Since my last discussion last month I've conducted some research regarding Ryzen and 16-bit/32-bit VMs, and apparently there seems to be a bug involving VME (Virtual-8086 Mode Enhancements). The INT instruction apparently misbehaves in V86 mode with VME enabled. More details are explained in the article below.

VME Broken on AMD Ryzen | OS/2 Museum

So then I realized, even though it is never mentioned, that not only Windows 98 (which is what I'm having problems installing) is effected but possibly any 16-bit (DOS/Windows 3.1) or 16-bit/32-bit hybrid (Windows 9x) operating system is effected (the article may state that 32-biy OS's are effected but I do have a Windows XP VM myself, it installed fine and it runs fine on Ryzen). The article states that people are having problems running 16-bit applications in DOS boxes in Windows VMs, especially in Windows XP (but I don't intend on running any 16-bit applications on my Windows XP VM).

So the article states the workaround is masking VME, but I would like to know what the precise string is to paste into the VM config file to test on the Windows 98 VM to see if masking out VME fixes my installation problem just so I know I'm posting the string of code correctly because I've mentioned before I have limited knowledge in CPUs. Thanks.

21 Replies
bluefirestorm
Champion
Champion

VME should be bit 1 of EDX register in CPUID function 1.

I think for AMD CPUs, the masking should have a .amd after the register. Try adding this line.

cpuid.1.edx.amd = "----:----:----:----:----:----:----:--0-"

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

Didn't work.... Absolutely sickening.

Reply
0 Kudos
bluefirestorm
Champion
Champion

I am pretty sure that the masking bit 1 in EDX in CPUID function 1 in Intel CPU works. I can verify this in a CentOS VM, "vme" will no longer appear in proc/cpuinfo flags once I masked that bit off.

I just looked up the AMD manual, it looks like there are two CPUID functions that has the VME identifier for AMD CPUs. I don't know which one takes precedence. I don't have a system with an AMD CPU to try this. You could also add

cpuid.80000001.edx.amd = "----:----:----:----:----:----:----:--0-"

Alternatively, you could try nested virtualisation (i.e. run the Windows 98 VM inside another VM) but the key here is that the Windows 98 VM should be using binary translation and not using hardware assisted virtualisation. I am assuming if the flaw is in the virtual 8086 mode inside the AMD Ryzen chip, perhaps using binary translation will avoid having that flaw invoked.

Example: you could create an ESXi VM and but don't expose the hardware virtualisation to the ESXi VM (thus it can only run 32-bit/16-bit OS inside). Or you could create a Linux VM and run VMware Player or Virtualbox or some other type 2 hypervisor software inside this VM but use binary translation for the Windows 98 VM that will be running inside this Linux VM.

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

The second string didn't work either, I'm not sure if adding both strings you gave me to the config file is a good idea or not. But if that's out of the question, what flavor of Linux would you recommend for this or does it really matter?

And I'm willing to bet that most if not all Intel users (and possibly older AMD users) have successfully installed Windows 98 without having to do any masking.

Reply
0 Kudos
bluefirestorm
Champion
Champion

I didn't click on the link in your original post. I am just replying on your need to disable VME. I am not familiar with AMD CPUs. I never owned a system that had an AMD CPU. You could try to add both. Nothing to lose with what you're trying to accomplish.

As to which Linux distro, it depends on a number of factors: your comfort level, compatibility with Workstation Pro, compatibility with the type 2 hypervisor that will be running inside. I would think you could go with Ubuntu 16.04 or CentOS 7. As to the type 2 hypervisor, I am not sure if Workstation Player 12.5.x still supports binary translation even though the options are still available in the VM processor settings. I haven't used other type 2 hypervisors in a long time: Virtual Box, QEMU, etc; so I have no idea which specific versions supports binary translation.

Again, if the theory is that there is something wrong within the AMD Ryzen chip, binary translation MIGHT be able to avoid triggering the memory fault in the Windows 98 VM installation that you have been encountering.

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

Sorry for the late reply, I decided to take a break from this whole Windows 98 thing for a bit plus I got busy with other things.

So I was considering installing Ubuntu 16.04 but I saw that you mentioned binary translation. Kind of a stupid question but wouldn't I be able to use binary translation right from the host (Workstation 14 Pro on Windows 10 Pro)? I've looked in the Workstation 14 Pro manual and it does mention "Disable acceleration for binary translation" but that feature is nowhere to be seen in vm settings on any of my other vm's or while installing Windows 98.

Reply
0 Kudos
bluefirestorm
Champion
Champion

I don't think Workstation Pro 14.x supports binary translation anymore.

In 12.x, there are four options in the Processor settings of the VM


Automatic - VMware software decides

Binary translation

Intel VT-x or AMD-v

Intel VT-x/EPT or AMD-V/RVI

One of the major internal changes for version 14.x was Extended Page Tables (EPT) became required for Intel CPUs (basically anything from Nehalem or earlier won't work with version 14.x). Another part is that Intel VMX Unrestricted Guest is also required (aside from EPT). Unrestricted Guest requires EPT. RVI would be the equivalent of Intel EPT. I don't know what or if there is an AMD equivalent of Intel Unrestricted Guest.

You could try adding the following entries to the vmx of the Windows 98 on version 14. I don't know if version 14 will allow it. But it will be the equivalent of the "Intel VT-x or AMD-v" option and thus will not use RVI. If RVI in the Ryzen CPU is part of the problem, perhaps that is also something worth trying before embarking on the nested virtualisation.

monitor.virtual_mmu = "software"

monitor.virtual_exec = "hardware"

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

So I just ran a total of five Windows 98 test vm's

The first two vm's I copied and pasted the two strings you just gave me, with and without the two cpuid strings you also gave me, Workstation 14 didn't seem to have a problem with those strings as I got no error messages whilst powering on the vm. The third vm I removed the ".amd" from the two cpuid strings. Now for the fourth and fifth vm's I came across a thread that explained VMware Products and Hardware-Assisted Virtualization (VT-x/AMD-V) and I found that the following string enables binary translation.

monitor.virtual_exec = "software"

So even though having in mind that Workstation 14 no longer supports binary translation I daringly added the string to the the config files to test vm's 4 and 5 (With and without the two cpuid strings) and it also didn't seem to be bothered by that.

All five test vm's showed the EXACT same scenario with the same error messages halfway through installation...

I suppose I could go for nested virtualization but another factor could be that my AGESA version (currently at 1.0.0.6a) is not up to date, I've seen during my research that anyone who has a version any older than this has had problems installing Windows XP and Windows 2000 with VME being the culprit and I have found that AGESA 1.0.0.6 seems to fix most if not all of the VME bug. But I guess that's not the case for Windows 98 or any other Windows 9x version and it still really bothers me that no one online has really said anything about Windows 9x OS's being affected on Ryzen and a workaround to get them to install and work properly. Plus, Windows 98 is turning 20 in May, I could possibly imagine lots of enthusiasts attempting to install it in a vm with a Ryzen processor to commemorate it's 20th birthday only to to their utter disappointment and disgust that they have similar problems if not the exact same problem that I'm having and not knowing of a workaround but hopefully there will be something by then. I currently don't think that updating my BIOS would be worth doing as I don't think there's any more fixes for VME.

Reply
0 Kudos
bluefirestorm
Champion
Champion

When Workstation 14.x was still in beta (aka 2017 Tech Preview), I tried the vmx settings for binary translation for an Intel CPU that does not have EPT. That is how I found out that not only was the user interface to change the virtualisation mode dropped but the support for it underneath was also dropped (at least for Intel CPUs) as the VM would not power up any more.

I haven't found out if AMD has an equivalent to the Intel Unrestricted Guest (which relies on EPT). Because that might be part of the problem. Basically Unrestricted Guest (aka IA-32e mode) allows protected mode.

On version 12.5.9, if I change a Windows 98 VM to use binary translation, I get the message

Binary translation is incompatible with long mode on this platform. The virtualization engine will automatically switch to Intel VT-x if the guest enters long mode.

If I look at the vmware.log file

vmx| I125+ Binary translation is incompatible with long mode on this platform. The virtualization engine will automatically switch to Intel VT-x if the guest enters long mode.

vmx| I125+ ---------------------------------------

vmx| I125: HV Settings: virtual exec = 'dynamic'; virtual mmu = 'software'

Maybe you can try monitor.virtual_exec = "dynamic" instead of "software"

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

When I powered on the vm with that string, it said is was not valid and was replaced with monitor.virtual_exec = "automatic" instead of "dynamic". And no that also didn't work.

In case you haven't seen them in my previous posts these are the error messages I always get, it happens after the third restart right when the date & time settings are supposed to come up.

pastedImage_0.png

pastedImage_1.png

Reply
0 Kudos
bonnie201110141
VMware Employee
VMware Employee

Looks you are using the correct mask strings:

cpuid.80000001.edx.amd=----:----:----:----:----:----:----:--0-

cpuid.1.edx.amd=----:----:----:----:----:----:----:--0-

It might be a bug in AMD CPU. For the Ryzen line of CPUs, it looks like this issue was fixed in microcode patch level 0x8001129. It would be great if you could update their BIOS to determine if that resolves this issue. If it does not, please provide .vmx file and vmware.log (with debug level set to full).

At the same time, we will try to reproduce this locally. Thanks!

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

I have updated my Gigabyte BIOS to F21 with AGESA 1.0.0.0a (I believe) and have just ran two Windows 98 vm's with and with out the two cupid mask strings, EXACT SAME result!!!

So I ran a third Windows 98 vm with full debug mode for you.

Here are my .vmx and vmware.log files, Hope you can get the word out! Thanks!

Reply
0 Kudos
bluefirestorm
Champion
Champion

It looks like you have allocated an 8GB virtual disk, USB 2.0 controller, and sound card.

The path to the VM is drive U:\ which I presume to be an external USB drive (which is probably the Seagate drive that the VM also sees).

Anyway, several suggestions, I leave it to you to try them or not, all at once or by one-by-one.

  1. Downsize the Windows 98 VM virtual disk to 1GB.  Since we're reducing the disk size, reduce the memory from 256MB to 128MB or 64MB. The rational is to avoid possible complications with volumes larger than 2GB (FAT16/32).
  2. Try removing the USB controller or keep it at only USB 1.1 compatibility. Win98 SE supports only USB 1.1 anyway.
  3. Try removing the sound controller. The Win98 SE ISO does not install the sound drivers. The drivers would have to be downloaded separately from the Creative website. http://support.creative.com/downloads/download.aspx?nDownloadId=259
  4. Try using a built-in disk of the host instead of an external USB disk; assuming drive U is indeed the external Seagate drive and the Windows 98 ISO is also located there. It did a few resets of the virtual USB mouse and USB hub controller. If it did reset and somehow affected the host USB controller, it could have led to the loss of access to the virtual CD (the ISO on drive U) and/or virtual disk (the VMDK on drive) so it isn't hard to imagine why installation will fail mid-way. Note I have no proof the resets are the cause, some of the reset entries might actually the after effect of the crash.

2018-02-28T19:59:41.286-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:00:03.258-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:00:03.364-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:04:14.512-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:04:14.613-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:07:38.162-07:00| vcpu-0| I125: UHCI: Global Reset

2018-02-28T20:08:03.025-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:08:03.136-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:08:03.265-07:00| vcpu-0| I125: UHCI: HCReset

2018-02-28T20:08:14.590-07:00| vcpu-0| I125: UHCI: Global Reset

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

I never allocated the 8 GB virtual disk although I did before and it didn't resolve the issue.

U:\ is a partition on my 2 TB Seagate internal hard drive so it's not external, but coincidentally I have a Seagate Backup Plus Hub 8 TB USB 3.0 external drive which is actually E:\ not U:\ and I don't think the external drive is included in the Windows 98 vm's settings (unless you actually did see the Backup Plus in the .vmx or vmware.log files).

As for your four suggestions:

     1. I've already reduced the size to 2 GB once before and I also adjusted the RAM as little as 64MB with no success, but I'll try it with 1 GB. Many people on Youtube have had an uneventful      installation with 256 MB of RAM and an 8 GB virtual disk.

     2. Already done those two USB things.

     3. I'm fully aware that Windows 98 vm's require sound drivers but since I'm unable to even get to the desktop at this point I never bothered to mention it, but I'll try removing the sound controller.

     4. As I stated above, U:\ is a partition on the internal hard drive not external. USB was one of my first thoughts behind this issue because I know Windows 98 can be a bit persnickety with USB      devices.

I'll list my PC specs

Motherboard: Gigabyte Aorus AX370 Gaming K5

Processor: AMD Ryzen 7 Eight-Core Processor 3.00 GHz

RAM: 16 GB DDR4

SSD: Samsung SSD 960 EVO 250 GB (This is where C:\ is, where Windows 10 and most of my programs (including Workstation 14 Pro) are).

HDD: Seagate Barracuda SD2000DM006 2 TB (This has three partitions with U:\ being one of them where my vm's and iso's are located).

External Hard Drive (Back-up): Seagate Backup Plus Hub 8 TB (USB 3.0)

ASUS DRW-24F1ST c CD-ROM drive

Graphics Card: ASUS GeForce GTX 1050 Ti

Host Operating System: Windows 10 Pro x64 Version 1709 (Build 16299.248)

Two-Monitor Setup: Both are ASUS VS248 Resolution is 1920x1080

Speakers: Bose Companion 5 USB 2.0

Keyboard: Logitech USB 2.0

Mouse: Microsoft USB 2.0

So at present there are three USB 2.0 devices and one USB 3.0 device, maybe one of these could be behind the problem.

I'll try again with some of your suggestions sometime tomorrow if not later today but I don't think they'll work, and keep in mind that I've already tried the following methods below so far.

Dialing down the hardware version

Setting USB compatibility to 1.1 in vm settings

Removing the USB controller

Splitting the virtual hard disk into multiple files

Reducing the hard disk size to 2 GB

Adjusting the RAM as low as 64 MB

Enabling "Virtualize Intel VT-x/EPT or AMD-V/RVI" in vm settings

Masking the CPU

Enabling binary translation

Using a different .vmx file from a different source

Using a different ISO from a different source

Reply
0 Kudos
bonnie201110141
VMware Employee
VMware Employee

I have filed an internal bug to track the issue. Let 's see how it proceeds. Thanks for your logs. We can reproduce it as well.

Reply
0 Kudos
bonnie201110141
VMware Employee
VMware Employee

Hi SanAndreasElevator,

Can you attach a screenshot and vmware.log with VME masked? Thanks!

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

Not sure what you want a screenshot of but I assume it's of the error messages I get, so I have two screenshots and the vmware.log file with both strings for masking VME added (see below).

I also have debug level set to full.

pastedImage_0.png

pastedImage_1.png

Reply
0 Kudos
bonnie201110141
VMware Employee
VMware Employee

Thank you for your quick response!

Reply
0 Kudos
SanAndreasEleva
Enthusiast
Enthusiast

Sorry for the absence. I have tried a 1 GB virtual drive, removing the sound card and unchecked "Automatically connect new USB devices" in settings, Same issue. I've attached a new vmware.log file with the USB controller removed, how about taking a look at that and see if you can find any other abnormalities compared to your Win98 installation.