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-"
Didn't work.... Absolutely sickening.
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.
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.
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.
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.
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
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"
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 126.96.36.199a) 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 188.8.131.52 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.
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"
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.
Looks you are using the correct mask strings:
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!
I have updated my Gigabyte BIOS to F21 with AGESA 184.108.40.206a (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!
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.
- 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).
- Try removing the USB controller or keep it at only USB 1.1 compatibility. Win98 SE supports only USB 1.1 anyway.
- 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
- 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
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