Page 4 of 4

Re: AMD-V with Ryzen not yet supported?

PostPosted: 29. May 2017, 08:03
by socratis
A "microcode update" is still a software update and a really harder one to implement and deploy. And as long as AMD has not released one, then VirtualBox has to work around it, until (and if) such a microcode update ever happens. And even then, the workaround would still be in the VirtualBox code, it will never go away...

Re: AMD-V with Ryzen not yet supported?

PostPosted: 30. May 2017, 10:06
by michaln
We have reported the problem to AMD. The workaround (not "hack") has to stay in place until we have information about how to distinguish Ryzens with working vs. non-working VME.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 30. May 2017, 10:24
by socratis
michaln wrote:The workaround (not "hack")
Off-topic question maybe, but when wouldn't a "workaround" like this be called a "hack"? You check your CPU, and if it's one of the affected ones, you modify the CPU leafs to present something different, to impersonate another CPU, right? I mean *I* could call it either, but why specifically a "not hack"?

Honest question, maybe a little two much in the fine details of the English language? ;)

Re: AMD-V with Ryzen not yet supported?

PostPosted: 30. May 2017, 13:14
by michaln
A hack implies something that could (or should) be done better, but it's quick and simple and does most of what's needed. A workaround means something that works around a bug (typically someone else's bug) in a way that solves the problem while triggering a minimum of negative side effects.

A workaround is a non-optimal but typically the best possible solution. A hack is by definition not the best possible solution.

In this particular case, we can't fix the CPU (that would be the optimal solution) but we can make the problem invisible for 99.99% of affected users (which makes it the best possible solution). I hope that makes some sense.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 30. May 2017, 14:10
by socratis
Yes, it does. As in:
Hack: we quickly hacked together a quick and dirty solution.
Workaround: we thought of this thoroughly and found a safe working solution.

And yes, it was the fine details of the English language, but once you explained it, terms like Hackathon and hack* started being "clearer".

Thank you ser!

Re: AMD-V with Ryzen not yet supported?

PostPosted: 31. May 2017, 11:17
by michaln
There will be a fix coming from AMD in the form of a microcode update (embedded in updated BIOS). When that will actually become available to users is unknown and depends on OEMs.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 14. Jul 2017, 15:17
by metastatic
michaln wrote:There will be a fix coming from AMD in the form of a microcode update (embedded in updated BIOS). When that will actually become available to users is unknown and depends on OEMs.


Any update on this? Has a microcode update been released, which resolves the issues raised?

Re: AMD-V with Ryzen not yet supported?

PostPosted: 14. Jul 2017, 16:49
by socratis
I'm afraid you should ask AMD about that, not Oracle.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 14. Jul 2017, 17:00
by Perryg
Actually the microcode update would come from the motherboard manufacture as provided from AMD. That makes it take a lot longer if at all, but that's the way it happens.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 14. Jul 2017, 18:38
by michaln
metastatic wrote:Any update on this? Has a microcode update been released, which resolves the issues raised?

AMD did their part and released the fix in AGESA 1.0.0.6. Whether an update is available for your board is something you need to check with your OEM.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 18. Jul 2017, 14:45
by metastatic
Thanks for the informative reply. It is appreciated.

Re: AMD-V with Ryzen not yet supported?

PostPosted: 26. Sep 2017, 16:27
by Thorshall
I use the AGESA 1.0.0.6b with ryzen 1800x. And VirtualBox-5.1.28 is working perfectly. :D

Re: AMD-V with Ryzen not yet supported?

PostPosted: 1. Feb 2019, 22:47
by wdeviers
I am supposedly running AGESA 1.0.0.6 (but not 6b) on an MSI board. I copied an XP VM from a previous machine to a new Ryzen 2 2700x box. Virtualization is on in the BIOS and detected via lscpu. VirtualBox warned me to turn CPU virtualization off, and I did. The options are now disabled. I ran

modifyvm a2858727-f303-46cd-b44a-90af035aa114 --cpuidset 1 00800f11 00000800 56d8220b 078bfbfd


as suggested. My XP VM still hard-locks during boot on version 6.0.5-128513 installed from the .run file on Arch Linux. Attached is the most recent log and output of lscpu.

Is this expected before 1.0.0.6b or merely before 1.0.0.6? I'm going to ask MSI either way. Thoughts appreciated!