37 Replies Latest reply on Feb 6, 2018 11:46 AM by stacey.leibermann

    Why is VME still broken on my Ryzen system?

    stacey.leibermann

      I bought a 1700x with a Gigabyte Gaming 3 motherboard.  I updated BIOS to whatever the new one was at the time (I think F5), and my computer worked well; RAM overclockability was garbage, but I didn't really care @ the time.  Chip hasn't been overclocked yet (it is currently plenty fast for my needs), it's cooled with a Noctua D14 cooler (generally doesn't go over 50°C), RAM is 2933 (currently 2133 after the BIOS update), and my system will pass every benchmark/stress test that exists.

       

      I built my system, and after a few days of stability testing, I installed Hyper-V, and created a few VMs, and noticed that all of the x86 VMs will crash the host OS in a few minutes.  Popped on Google, saw this was caused by AMD's improper implementation of VME.  I have been using Win x64 VMs for months now, as well as a bunch of Linux ones, with no issues, so it seems very likely VME is the issue, or some other instruction set that Win x86 uses that x64 doesn't.

       

      A few months ago, AMD claimed there was a VME fix with microcode 8001126.  As soon as I could, I downloaded the update that had this microcode (AGESA 1.0.0.6a); same issue.  E-mailed Gigabyte on July 5th, and they replied on July 10th saying the fix was coming with AGESA 1.0.0.7 (I have a feeling they meant 1.0.0.6b?), so I waited.  BIOS F8 came (I never installed this one, since it had no AGESA update), then F9D came, which had AGESA 1.0.0.6b.  After updating to this F9D BIOS, I verified that I got new microcode 8001129 (verified with HWInfo64) ... still the same issue.

       

      I posted on reddit, and others still have the same issue with their updated BIOS on their boards.  Is the problem my CPU, or is my problem my motherboard?

       

      Another random tidbit: when I was originally trying to display the current microcode for my CPU, I ran SiSoftSandra's processor information tool (it's not benchmarking the processor, but rather seems to be trying each instruction for capabilities) and it consistently crashes my system after maybe 40 seconds.

       

      I'd really like to know what my options are.  I actually "need" Win x32 OSes for a bunch of VB scripting in Excel/AutoCAD that are considerably faster in Win x32 than x64.  I mostly used Win 7 x32 VM OSes, but I tried Win 10 x32 for comparison, and it crashes the same.

       

      Edit: Bought my CPU/motherboard Apr. 29, 2017

      Edit 2 (Sept. 20):

      OS: Windows 10 x64 Pro w/Hyper-V installed (fully updated)

      CPU: AMD Ryzen 1700x running stock everything, (CPUID: 00800F11, Stepping: ZP-B1, Microcode: 8001129, SMU Firmware: 25.82.0)

      Motherboard: Gigabyte AB-350-Gaming 3-CF (BIOS F9D; issue exists in all BIOS) (AMD 17.30 drivers installed)

      RAM: 16GB (2x8) of Corsair CMK16GX4M2B3200C16 running 1066/15/15/15/36/51 (default)

      GPU: MSI GTX 1070 Gaming X (stock everything) (nVidia 22.21.13.8476 drivers installed [384.76])

      Drives: Samsung EVO 960 500GB NVMe, Samsung Evo 840 256GB, 2x Toshiba MD04ACA500 5TB (non-RAID) (Samsung v2.2 driver installed)

      Monitors: 3x Dell U2412M @ 1900x1200

      USB stuff: (USB Host 1: Logitech Keyboard, Mouse, Garmin watch, USB stick ... USB host 2: APC UPS, HP LaserJet 1020) (All Microsoft drivers)

       

      Using the Ryzen Balanced power profile, but using High Performance changes nothing with respect to my issue.

        • Re: Why is VME still broken on my Ryzen system?
          stacey.leibermann

          Nothing from AMD?  This seems like a common-enough issue that you'd either be able to say "it's still broken, we're working on it", or "its your motherboard provider; this doesn't happen for everyone", or something.

           

          Every person I've been able to get to test this has the same issue, so it definitely seems like a Ryzen issue.

          • Re: Why is VME still broken on my Ryzen system?
            qwixt

            I saw someone selling a 1800x on amazon, and that person mentioned this virtualization bug. I didn't really think about it much. But after reading your post, it pretty much kills any decision to try ryzen. I have run into issues using virtualbox and Hyper-v on win 10 64 bit with intel processors too. But they were able to run much longer than 40 seconds. The guest OSes were all linux though.

              • Re: Why is VME still broken on my Ryzen system?
                stacey.leibermann

                It, admittedly, doesn't impact most random consumers; not many people run Hyper-V, and even less run Windows x86 OSes inside those VMs.  However, for those it impacts (me), it's a pretty big deal (this is LITERALLY one of the reasons I bought this system ... even waited a year instead of purchasing a 5820k).  What bothers me is AMD claims to have fixed my issue (news), but it appears to have been a lie to appease review sites, which is brutal.  I'm now wondering if my issue is somehow related to the segfault glitch that Linux people are seeing, which would mean a simple RMA with an updated chip might fix it.  However, not a lot of response from AMD in either this thread (obviously), or through their support system (10 days so far).

                 

                You see a bigger problem is when you start looking at something like Threadripper; these are more likely to be used for virtualization, and since it is just two Ryzen chips, they will presumably have the same bug (I haven't found anyone who can test for me); the likelihood of THOSE people running Hyper-V is considerably larger.

                  • Re: Why is VME still broken on my Ryzen system?
                    qwixt

                    From what I have read, the segfault compile issue did not affect Threadripper, so this might not happen with threadripper. If I was in your situation, I RMA it for the segfault issue since it's one of the early chips. It doesn't hurt to try a new cpu as far as I am concerned.

                      • Re: Why is VME still broken on my Ryzen system?
                        stacey.leibermann

                        Actually, you're probably right, since the Threadripper CPUs would have probably been built after they figured out the issue.  I'd love to do some tests on Threadripper CPUs running Hyper-V to see if the VME issue exists on their chips.  If not, then (as you said) the RMAed chip would probably resolve that issue for me as well.

                         

                        As I sit, I'm technically waiting on an answer from AMD about an RMA for my chip; doesn't seem like they're too speedy with replies.

                         

                        Edit: As per replies below: yes, the VME bug exists in Threadripper.

                  • Re: Why is VME still broken on my Ryzen system?
                    stacey.leibermann

                    Here's an update, in case anyone ever searches this out: VME is still very broken on AMD Ryzen chips (at least until CPUs from week 37, which is what my newly RMAed chip is).

                     

                    Current BIOS for my Gigabyte GA-B350 Gaming 3 is still F9D (which was the AGESA 1.0.0.6b BIOS), so a newer one might resolve this VME issue, but I doubt it.  AMD claimed that they fixed it back in May, but it appears that either the motherboard vendors never got this fix, or they believed they'd found a fix, but actually didn't (or they lied, to get news outlets off their backs).  I've seen this bug manifest itself on x370 motherboards as well, so it's not unique to my cheaper B350 chipset.

                     

                    With Hyper-V, at this point, you can not resolve this issue; Hyper-V determines the CPU's capabilities from the chip itself, and the chip claims to support VME, but that doesn't work.  With other VM software, you probably can, by not allowing the guest OS know that the chip is capable of VME instructions (obviously varies by VM software).

                     

                    Very disappointing.  AMD doesn't do cross-shipping/advance RMA, so you need to find a CPU while you ship yours out. When they receive your returned CPU, they process it (probably check if it was physically damaged), and ship the replacement chip  back (in my case, from Canada, that was about 2 weeks ... I never got a confirmation that the CPU was on it's way back to me, so I am not sure how much of that was shipping).  As well, AMD accepted my RMA, when the should have just told me "that is still a bug"; my CPU was working fine, except for this VME bug, so they should have just told me they didn't fix anything with the new chips, instead of wasting my time (and money, buying a chip that I then will be returning ... hopefully.

                      • Re: Why is VME still broken on my Ryzen system?
                        esargent@aol.com

                        I have the same issue, Threadripper 1900x on MSI Pro Carbon board.  Latest BIOS (1.6) only includes AGESA 1.0.0.3a, so I've been spamming MSI in an attempt to prompt them to update the BIOS with the AMD "fixed" version.  Was very disappointed to see your report that there isn't really a working fix.  I'm a developer who built this machine for that purpose, but, since I frequently need to run 32bit VMs in hyperV, I'm stuck.  All 32bit VMs crash within minutes (actually completely lock up the machine), whereas, 64bit VMs are fine.  Please continue to keep us updated on your situation, I (and several other colleagues) am following this post hoping that you'll attain a resolution that we can then mimic.

                        1 of 1 people found this helpful
                          • Re: Why is VME still broken on my Ryzen system?
                            stacey.leibermann

                            That is disappointing to hear about Threadripper; I would have hoped they'd have shipped those, by default, with the VME fix, but since they didn't, it does seem to agree with my guess that the apparent VME fix was just a lie to appease news outlets ... unfortunate.

                             

                            As for AGESA stuff, everyone with a Ryzen board should be on AGESA 1.0.0.6b, which was released early Sept. (or 1.0.7.2a, for everyone on the BIOS released a few days ago [early Dec.], more on this later).  So it seems the Threadripper AGESA numbering scheme doesn't match Ryzen, which I suppose makes sense given the structural differences between the two platforms. As well, MSI doesn't seem to actually indicate which AGESA came with which BIOS, but I see "improved memory compatibility" came with BIOS 7B09v15 in early Sept., I'd assume THAT is where an AGESA update came, so 1.0.0.6b (Ryzen) ~= 1.0.0.3a (Threadripper) with respect to general bug fixes.

                             

                            Now, I actually JUST got the AGESA 1.0.7.2a BIOS released for my B350 board on Friday, which makes me excited because people WERE calling it 1.0.0.7, and Gigabyte told me that the VME fix was coming with 1.0.0.7.  However, I am wary of installing it since there were bugs that were found that delayed the release of updated BIOS for OTHER Gigabyte boards.  I am therefore wondering if, while fixing THOSE bugs, they'll uncover bugs on MY board, so I am trying to wait for everyone to get this new update (in case they release an F10a, for example) before risking the BIOS update.

                             

                            As with you, my PC is a work machine, so I can't be having flaky BIOS, so I am getting pretty antsy trying not to install this BIOS yet.  Once I do, if VME is still not fixed, that probably bodes poorly for any update you'd be getting in the near future. I have tomorrow off, so I'll potentially do some BIOS updates tonight.

                             

                            Edit: Bad news, and maybe so-so news.  Bad news is that F10 (AGESA 1.0.7.2a) did not appear to fix VME at first glance; my workstation runs pretty tough loads on a daily basis, so I am pretty confident of it's general stability, but firing up a Windows x86 VM still crashes the computer after the VM is operating for about 2 minutes.  Curiously, the VM snaps between using 6% (100% one thread), and 12% (100% 2 threads) as it sits at the login screen until it crashes out; maybe my Windows 7 VM is trying to get Windows updates or something; not sure.

                             

                            Not so bad news is that, instead of the computer crashing to a black screen with fans all @ 100% needing a reset, instead it just locks up ... still needing a reset .  So, there is a CHANCE that my PC is just outright unstable with F10, and will require more testing.  So, for now, I will try to just ensure my PC is stable generally, then see if I can get Windows x86 to play nice.  I will probably re-create the Windows x86 VM, just in case something happens during the OS installation that might need to change (maybe during installation the OS makes changes based on knowledge of a VME capable CPU? I don't know).

                             

                            My CPU still has the same microcode (8001129), so nothing changed on that front.  I might try and get a hold of a backup videocard for "testing" (I'm looking at you, Vega 56), to be sure that's not the problem (I have VERY little faith in nVidia's drivers).

                            1 of 1 people found this helpful
                              • Re: Why is VME still broken on my Ryzen system?
                                esargent@aol.com

                                I guess I don't really know the AGESA version for certain, I'm using a tool called AIDA64 to determine.  It is showing AGESA Version SummitPI-SP3r2-1.0.0.3A, BIOS version 1.60 dated 11/14/2017. 

                                 

                                I've logged support tickets with both AMD and MSI hoping for some confirmation that they are at least aware of and working on the issue, but so far (2 weeks) the only response has been that my ticket was forwarded to the appropriate party.

                                1 of 1 people found this helpful
                                  • Re: Why is VME still broken on my Ryzen system?
                                    stacey.leibermann

                                    You most definitely are on AGESA 1.0.0.3. Not sure how the "A" part relates, but Gigabyte boards are on 1.0.0.3 patch 4; I'd presume those both mean the same thing.

                                     

                                    As for waiting for an answer: you'll be waiting a while ... doesn't seem like AMDs departments have any sort of meaningful internal communication, which is surprising and unfortunate. If you ever get a reply, please let me know here.

                                     

                                    As I noted above, AMD authorized an RMA for my chip when my only complaint was VME wasn't working, when they should have known that the VME bug wasn't yet fixed.

                                      • Re: Why is VME still broken on my Ryzen system?
                                        esargent@aol.com

                                        Possibly AMD monitors these forums and saw my post about not getting a reply, because they responded at 6:34am this morning.  They just asked a bunch of questions about my build, which 32 bit guest O/Ss I was experiencing the issue with (I've tried VistaSP2, Win7pro, Server 2003ent, and a couple of flavors of XP).  So I'm not sure that they are on the same page yet, but at least they've tasked someone to look into it.  I specifically mentioned the VME bug in my ticket, so hopefully they connect with someone in engineering to find out the status once they've gone through their preliminary standard support checklist. 

                                        2 of 2 people found this helpful
                                          • Re: Why is VME still broken on my Ryzen system?
                                            stacey.leibermann

                                            I've potentially found out something very interesting by accident, but I've only tested with Windows 7 x86, and Windows 10 x86 so far, but these "bare" Windows VMs are not crashing!  When I make a new VM, they're now configuration version 8.2. You can upgrade your VM version, but as I found out later, it doesn't seem to fix whatever is busted in my old VM.

                                             

                                            Previously (a few months ago), I'd installed Windows 10 x86 and had the exact same VME issues as with Windows 7 x86; I am not sure if I installed Windows 7 x86 and upgraded it (probably did), but the problem definitely persisted with Windows 10 x86 without a doubt anyways.

                                             

                                            Now, today I installed a Windows 10 x86 VM a few hours ago directly from my original Win 10 ISO (which is old on purpose, because I can generally trigger a crash quickly by running Windows Update on my Win7 VM), and immediately noticed a few enhanced Hyper-V features came with config 8.2, namely auto-checkpoints.  The only reason I even knew that this enhancement was a thing is because any update with Hyper-V I pay attention to (I'd read about them from the Fall update, but noticed it wasn't happening with my existing VMs ... didn't think much of it, because I don't really need this feature). After I was confident the Win 10 x86 one was reasonably reliable, I installed a Win 7 x86 one and updated it fully; at the time of taking that pic, the VM was in process of updating.  It has now gone through the round of updates that comes with all the .net Framework patches (so, one of the last patch sets) and has been running for about 20 minutes. (Update: With all updates, it ran for 2 hours before I got impatient and installed Office).

                                             

                                            Preliminary tests seem to indicate that this config v8.2 might help/resolve this issue (since just updating my BIOS did not solve it by itself); I'll do more testing, but I wonder what configuration version YOUR problematic x86 VMs currently are, if only for a simple data point. Sure it's only 1h20m (it was 3+ hrs before the last update reboot), but that x32 Scripting VM that is shown directly above the two test VMs will crash my PC in less than 15 minutes consistently, and it is at the exact same update level as the new VM is.  That problematic VM DOES have AutoCAD 2010, the VBA enabler, and Office 2013 installed, so not a perfect comparison, but sitting at the login screen, unless AutoCAD’s licensing server is causing issue, the two VMs should be nearly identical.  Once I can be reasonably sure these x86 VMs aren’t randomly crashing my PC, I’ll install Office, and update.

                                             

                                            For now, I am going to leave the Win 10 x86 VM and Win 7 x86 VM running, with NOTHING installed in them except all of their required Windows Updates, and see if the issue is "solved".  I am very optimistic about the Win 7 one, since it isn’t crashing.

                                             

                                            Edit: Funny what you can find when you know what to search for: What's new in Hyper-V on Windows Server 2016 | Microsoft Docs

                                             

                                            These appear to be changes to Hyper-V that were reported about a month before the the Fall Creators Update (which is when Configuration Version 8.2 seems to have been implemented); I would say that it's quite likely that they represent what changed.  Going by what is labelled as "new" in that article (unfortunately the links do not have dates, but the webpage source code claims it was "updated" on 2017-09-15, a few days before the source page was published), I am assuming this means these features outright didn't exist previously.

                                             

                                            On that linked page, the header labelled "Host resource protection" seems intriguing for us, as when you click the "Set-VMProcessor" link, and scroll to "CompatibilityForMigrationEnabled" or "CompatibilityForOlderOperatingSystemsEnabled", you can see that they've seemingly added capability for an alternate CPU/limited CPU to be exposed to the guest VM.  Now, while I personally haven't edited these parameters, check out the result of this command (I'm learning PowerShell !):

                                            In this list, the top VM and bottom VM are the new x86 VMs that are not crashing, and the middle VM is the one that is randomly crashing.  Note that the new "CompatibilityForMigrationEnabled" variable is "False" on the working VMs.

                                             

                                            Update: Changing either of those settings on my problematic VM seems to have no tangible impact on stability. Updating it to Config 8.2 had no impact on stability. As I posited before, its possible that, during installation of Windows, a change happens WRT VME that either "taints" the OS in some way, or "taints" the VM configuration in some way.  There might be a command hiding somewhere for what CPU to emulate for the VM which is set by Microsoft @ installation,  or even something as simple as "CompatibilityVirstualModeEnhancementsEnabled" = False and I just haven't found it ... or maybe we simply can't set it.

                                             

                                            Update2: So, I set a checkpoint with the Win7 VM to "just before AutoCAD", then I installed AutoCAD 2010 and 2016 (the previous Win 7 VM had both of these; forgot), and this VM hasn't crashed in 12 hours (idling). The crash-happy VM and the seemingly crash-free VM are now essentially identical, yet the one I made a few months ago crashes; weird.  I'll give it a week to see if it is stable, but it seems as though it is working now.

                                             

                                            Eventually, I'll test by imaging the "good" VM and installing it into the "bad" VM ... and vice versa ... to see if the crashing follows the OS or the VM.

                                            • Re: Why is VME still broken on my Ryzen system?
                                              esargent@aol.com

                                              So I got emails from this forum that partially outlined some other things that you tried, but the posts seemed to have disappeared from here.  Did AMD delete them or did you delete them once you realized they didn't work out?  Anyway, my HyperV configuration versions range from 5.0 to 8.0 on my broken 32-bit VMs, and I had attempted a fresh-from-old-iso install of VistaSP2 previously without success (it got through the whole install, but froze the machine during the first run of windows update after the first post-install boot).  I'll see if there are any updates to Server 2016 (that's what I'm currently running on my host, was originally running Win10, but switched to Server 2016 in the hopes it would fix the issue) that might give me the 8.2 configuration version [even though it didn't solve the problem for you, it sounded like you had longer periods of stability].  Interestingly, I used powershell to create a new VM with configuration version 5 (instead of the 8 that is default), using the same 32-bit VistaSP2 vhd, stopped/disabled the windows update service immediately upon boot, and had it not crash for almost 2 hours (that's a record for me, previously I haven't had a 32-bit VM last more than 10 minutes), so I had almost thought that I was on to something.

                                                • Re: Why is VME still broken on my Ryzen system?
                                                  stacey.leibermann

                                                  I edited my message a LOT of times; sorry about that, it was because I was finding out my guesses were wrong, and they didn't seem to add to the conversation.  There SHOULD be an update for Server 2016 to enable the same updates as I have to Hyper-V. If it does, and you want to try and replicate my "success", you create a new gen 1 VM (which will be configuration version 8.2), and install as normal.  Even though your BIOS doesn't have the potential VME fix mine does, I don't believe it will matter, as I believe Microsoft slipped a bandaid in there that comes along with the actual VHD file.

                                                   

                                                  At present, my two x86 VMs have been running for ~24 hours; I can confidently say that they're BASICALLY reliable as they currently sit (aka: they're not crashing while "idling" [which probably meant Windows Updates were happening in the background], which was always the case before).  Unfortunately, I've changed quite a few things since I built the crashy VM, but I am unable to make my crashy VM not crash, while it's virtual twin is working fine; if I can figure that out, then I will know where the problem is.

                                                   

                                                  Next change will be installing the customizations to my AutoCAD (custom menus, add-ins, etc), and start doing "work" with these VMs (basically, use Excel to run AutoCAD to do a LOT of things).

                                                   

                                                  Eventually, when I move the images between the VMs, I think I'll have narrowed down where the bugfix exists; my current guess is the VM internally holds some information about what CPU it was originally built with, and when Hyper-V reports that info to the internal VM, it uses that CPU, assuming Hyper-V determines the host CPU is capable.  This is a wild guess, with not a lot of solid reasoning, but it seems VERY odd that my current VMs are randomly conveniently not running ANY VME commands, while my old VM will eventually run one after ~1 to 15 minutes and crash the host.  Remember, VME is ACTUALLY not fixed with these CPUs (essentially, they're not capable of VME, which is unfortunate but shouldn't really matter), it just seems as though something along the way has enabled a guest VM to be able to ascertain that

                                                   

                                                  Configuration version itself seems to have no impact (aka: changing the config level after the fact doesn't bring a fix), changing CompatibilityForOlderOperatingSystemsEnabled seems to have no impact. Updating the VM seems to have no impact (aka internal update level of the internal VM doesn't seem to have brought a VME fix with it at some random point). BIOS level seems to have no impact (I am not willing to go back to F9D at this point to see if it will make my seemingly stable x86 VMs unstable). Again, this is all WRT any changes made not fixing my "patient zero" VM; one of those things DOES seem to have fixed my VMs, but I don't know how to apply this fix to an existing VM.

                                                    • Re: Why is VME still broken on my Ryzen system?
                                                      esargent@aol.com

                                                      Thanks for the details.  Unfortunately I can't go with a "fresh" OS install because some of the software that I have installed on those VMs came on CDs that are no longer good, rely on external licensing servers to "activate" that no longer exist, or even came on floppy disks that I no longer have any drives for (and probably aren't good anymore anyway).  The VMs that fail on my threadripper build all work fine on my 3 older machines (identical FX8350 cpu/msi g970 mb) running win8.1 and server 2012.  I've moved them back and forth multiple times and they always fail on the new system and work fine on the older hardware.  Possibly I'll just need to wait on AMD to create a VME fix and MSI to implement it, but my old hardware is nearing end-of-life.  The one test that I haven't tried, just to rule out that newer hyperv on Win10/Server2016 isn't the issue, is to throw a new drive in one of my older boxes and install Win10 and see if 32bit VMs crash it; I'll probably try that next weekend.  I might also log a ticket with Microsoft to see if they have any ideas, maybe there is some hidden/un-documented config flag that can force the processor to report itself as non-VME-capable. 

                                                        • Re: Why is VME still broken on my Ryzen system?
                                                          stacey.leibermann

                                                          You don't need a "fresh" install, you could potentially build a blank 8.2 VM, boot to imaging software on the problematic VM to create an image, and restore that image to the 8.2 VM.

                                                           

                                                          I know it's asinine, but who knows.

                                                           

                                                          You are right though, it would be better if AMD just admitted they haven't fixed VME and put somone on the task of solving it, or have AMD contact Microsoft in hopes they can add a fix that allows Hyper-V to disable VME manually.

                                                          • Re: Why is VME still broken on my Ryzen system?
                                                            stacey.leibermann

                                                            Ugh forget everything. As you said, once you make the OS actually do work, it craps out.  As well, once the VM craps out once, it is now "tainted" as well, and will crash after 1-15 minutes; nice.

                                                             

                                                            Come on AMD, why continue the lie that VME is fixed?

                                                              • Re: Why is VME still broken on my Ryzen system?
                                                                esargent@aol.com

                                                                Ugh, that sucks.  Back to waiting on AMD for a fix.  

                                                                • Re: Why is VME still broken on my Ryzen system?
                                                                  esargent@aol.com

                                                                  What about an approach from within the VM to prevent the OS from running anything that will trigger VME?  As near as I can tell, VME is only triggered by legacy 16-bit routines.  There is a registry key and/or group policy that I think will achieve the result of blocking 16bit applications.  I can't try it until later, but here's an article link that describes how to block them: Windows hole discovered after 17 years - Update - The H Security: News and Features

                                                                    • Re: Why is VME still broken on my Ryzen system?
                                                                      esargent@aol.com

                                                                      I set the VDMDisallowed flag in the VM to 1, and enabled the group policy to disable 16 bit applications.  Rebooted the VM.  Waited 15 minutes, ran a windows defender scan and opened a couple of Word documents, waited 10 minutes with task manager also open, then blam, system freeze.  So no effect, made no difference.

                                                                        • Re: Why is VME still broken on my Ryzen system?
                                                                          stacey.leibermann

                                                                          The thing with VME is you don't really need to use it; the CPU could execute the command slower by not using that capability, and these instructions are rarely used. Windows 2000 was the only one that blindly assumed VME compatibility regardless, so that OS will never work on Ryzen unless they actually fix it (probably won't), but everything else checks to see if the CPU can do it, and then does it.  In normal Windows, the CPU properly handles VME (not sure if it can do it, or if it just properly reports it is incapable of VME to the host OS), and everything runs nice.

                                                                           

                                                                          When things are virtualized, the CPU misreports its capabilities via a malformed CPUID.  I'm not sure if AMD are simply incompetent, or if the problem is more complex than simply editing the CPUID that is reported to disable VME @ the CPU level (because with other VM software, overriding that CPUID actually fixes everything), but the problem is the OS is being told "Ya, VME works", which it then says "Awesome, do this thing using VME".

                                                                           

                                                                          Now, in theory, you would be able to tell the OS "Don't use VME", but this feature would have been useless since computers automatically deal properly. I sent a message to a guy who claimed there existed a DisableVME flag somewhere, but I haven't found it myself. Another option would be to have something that captures VME instructions and stops them, but this would crash the program, since it won't have done what it was expected to do.  The last option would be to be able to edit that CPUID; I was REALLY hoping this functionality was available, but it doesn't seem to exist.  I'd expect this doesn't exist so that you can't lie to the OS and gain functionality that was artificially removed from CPUs (like, a Xeon and a normal Intel CPU are identical, but accelerated functions with xxxxx program will only work if you've shelled out cash for a Xeon).  If this capability DID exist, it would probably be in HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\<something> of the guest OS ... but I am not sure (yet ).

                                                            • Re: Why is VME still broken on my Ryzen system?
                                                              esargent@aol.com

                                                              On this page: https://docs.microsoft.com/en-us/powershell/module/hyper-v/set-vmprocessor?view=win10-ps  are a list of all the processor adjustments that can be made for hyperv.  I'm going to randomly try setting some of these to see if anything changes.  Maybe ExposeVirtualizationExtensions or CompatibilityForOlderOperatingSystemsEnabled will have some affect, who knows? 

                                                    • Re: Why is VME still broken on my Ryzen system?
                                                      stacey.leibermann

                                                      Update (rather, lack thereof): AMD appears to still have no fix for the VME bug, nor any intention of addressing it, and with Pinnacle Ridge (Zen+/Ryzen 2 / whatever) CPUs on their way, along with their new 4## chipsets, I have a feeling this bug will remain forever for these first generation chips; unfortunately.

                                                       

                                                      I'm now putting my hopes on Ryzen 2 solving this issue; once those are released, I'll see if I can get someone to test.  Maybe with all the benchmarking that will go along with these new chips, news outlets will be able to make some noise about this bug again (if it remains); seems like a super easy thing for a nefarious news source to test for on day 1 to make AMDs new chips look bad.

                                                       

                                                      Spectre/Meltdown update from Microsoft did not fix anything; word is there might be a microcode update that is needed to mitigate Spectre, so maybe they'll sneak in a VME fix while they're at it.

                                                      • Re: Why is VME still broken on my Ryzen system?
                                                        stacey.leibermann

                                                        esargent@aol.com Weird Update: So, I have a stable Win7 x86 VM running on my system.  It's been doing real-work for over an hour, and is stable.  I was unable to do this with my previous BIOS (F10, in my case, which should approximately match up with your 7B09v17), but the newest BIOS update (intended to add compatibility with the Ryzen refresh, also coming with AGESA 1.0.0.0), I am stable.  To be clear: the only thing I changed was going from BIOS F10 to F20c.

                                                         

                                                        However, and I figured this out completely by accident, the VM "will" crash if I give it two virtual CPUs, but not one.  I figured that out by accident, as I apparently had my Win 7 VM running with one core this whole time.  Since I had a stable system, I figured two CPUs might get me a bit of a performance boost for my tasks, so I rebooted the VM to change 1 vCPU to 2 vCPUs, and the host system locked up after about 15 seconds (which approximately matches up with how it used to crash with F10).

                                                         

                                                        TL;DR: AGESA 1.0.0.0 appears to have come with whatever is required to fix the VME bug, but might only work with a single vCPU.

                                                        1 of 1 people found this helpful
                                                          • Re: Why is VME still broken on my Ryzen system?
                                                            esargent@aol.com

                                                            When I put the 1.7 BIOS update on it didn't appear like the AGESA version changed at all.  I, of course, tried to run an x86 VM anyway and had it lock up the machine after about 20 minutes.  I'll try your trick about only using a single vCPU and see what happens...

                                                            1 of 1 people found this helpful
                                                            • Re: Why is VME still broken on my Ryzen system?
                                                              esargent@aol.com

                                                              18 hours, no crash on a Win7 32bit VM.  Apparently using a single vCPU somehow prevents the crash.  I started a Win Server 2003ent and a Vista VM, single core only, before leaving this morning to give it a real test, will report results when I get home.

                                                              1 of 1 people found this helpful
                                                              • Re: Why is VME still broken on my Ryzen system?
                                                                esargent@aol.com

                                                                I've had 3 x86 VMs running under light load for almost a day with no lockups.  All of them with only a single vCPU.  It appears to me like using a single vCPU is a viable work-around for the issue. 

                                                                1 of 1 people found this helpful
                                                                  • Re: Why is VME still broken on my Ryzen system?
                                                                    stacey.leibermann

                                                                    I have two VMs (Win7 x86 and Win 10 x86) that have been running for a bit over 2 days; no crash, but as you said, will only run with 1 vCPU.

                                                                     

                                                                    Unfortunate, as that is a very stupid limitation (bad enough for me, but even worse for you), but at least it seems to work.  What I find odd is that YOUR system works with what is the equivalent of my previous BIOS, yet mine did not work in that configuration.  I wonder if they care a bit more about Threadripper, and you got the fixes before me.

                                                                     

                                                                    Hopefully this information makes it out to AMD somehow, and they expand the VME fix to work when vCPU > 1.  In a few days, I am going to try 3, 4, 5, etc ... maybe if I'm lucky, it works for odd numbered CPUs or something.

                                                                    1 of 1 people found this helpful