virtualbox.org

I have a Yosemite VM running in VB 5.2.6 under macOS 10.13.3 on a 2017 5K iMac (i5)

In Settings/General/Basic when I set the Version of the VM to "MacOS X 10.10 Yosemite (64-bit)" I get a critical error 'Guru Meditation' on starting the machine.

If reset the Version to 'Mac OS X (64-bit)', i.e. generic, the machine will start normally.

Config and Log for the first case attached.

<CPU count="3">

Try with 1 CPU. 10.10 is really sensitive and not cooperating at all. It's a real pain if you have to work with it. Random crashes, non-cooperating graphics, bad audio, not really SMP... horrible.

This is one of the cases that I've used snapshots at its max. Take a snapshot:

• Launch 10.10, if it works, adjust a couple of settings, shut it down, take a snapshot, delete the previous one.
• Launch 10.10, if it doesn't work, revert to the previous snapshot.

Rinse and repeat.

socratis wrote: This is one of the cases that I've used snapshots at its max. Take a snapshot:

• Launch 10.10, if it works, adjust a couple of settings, shut it down, take a snapshot, delete the previous one.
• Launch 10.10, if it doesn't work, revert to the previous snapshot.

Rinse and repeat.

I did play with all sorts of settings before I thought about changing the version (number of CPUs, amount of RAM, amount of VideoRAM, hardware acceleration, 3D graphics etc), changing one variable at a time and a lot of rinsing/repeating

I guess I am not sure what benefit I get from setting the VM Version to other than generic. When I isolated the problem to being the Version I was happy - I now have a working VM that enables me to do the backward compatibility tests I need to do on my software (compiled on 10.13.3 for 10.10 onwards) but I guess I'm missing out on some optimisation that the OS Version enables. Until now, I had thought it was just a descriptive label, but apparently not.

Maybe this trick might help anyone else who encounters a similar problem, so I posted here to make sure there is a record of what I found.

granada29 wrote:Until now, I had thought it was just a descriptive label, but apparently not.

Same here... Could you do me a favor and post a VBox.log.ZIP from a run with the template set to the generic "OSX" instead of the "10.10"? I want to see what's different between them during runtime. Just launch the VM, login, shut it down. Post the log...

socratis wrote:Could you do me a favor and post a VBox.log.ZIP from a run with the template set to the generic "OSX" instead of the "10.10"? I want to see what's different between them during runtime. Just launch the VM, login, shut it down. Post the log...

VB Config and Log for installed OS X 10.10, with Version MacOS X (64-bit) attached.

Excellent! Thank you...
Now to the diffs between the two runs. The red ones are the "10.10" ones, the rest are the "generic" ones. The first two entries do not exist in the "10.10" run:

00:00:02.606124   MaxIntelFamilyModelStep <integer> = 0x0000000000061701 (399 105)
...
00:00:02.614165 CPU: CPUID(0).EAX 0x906e9 -> 0x10671 (uMaxIntelFamilyModelStep=0x61701, uCurIntelFamilyModelStep=0x69e09
...
00:00:02.628081 IEM: TargetCpu=CURRENT, Microarch=Intel_Core2_Penryn
00:00:01.555697 IEM: TargetCpu=CURRENT, Microarch=Intel_Core7_KabyLake
...
00:00:02.814622                               Model:  7 	Extended: 1 	Effective: 23
00:00:02.814623                            Stepping: 1
00:00:01.670271                               Model: 14 	Extended: 9 	Effective: 158
00:00:01.670272                            Stepping: 9

I think I know where this is going... faking the CPU.

After a little bit of search, that is indeed the case for guests up to 10.9. The "culprit" is at '/src/VBox/Main/src-client/ConsoleImpl2.cpp'. Pay closer attention to the comments:

[quote]
if (fOsXGuest)
{
    /* Expose extended MWAIT features to Mac OS X guests. */
    LogRel(("Using MWAIT extensions\n"));
    InsertConfigInteger(pIsaExts, "MWaitExtensions", true);

    /* Fake the CPU family/model so the guest works.  This is partly
       because older mac releases really doesn't work on newer cpus,
       and partly because mac os x expects more from systems with newer
       cpus (MSRs, power features, whatever). */
    uint32_t uMaxIntelFamilyModelStep = UINT32_MAX;
    if (   osTypeId == "MacOS"
        || osTypeId == "MacOS_64")
        uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482. */
    else if (   osTypeId == "MacOS106"
             || osTypeId == "MacOS106_64")
        uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */
    else if (   osTypeId == "MacOS107"
             || osTypeId == "MacOS107_64")
        uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out
                                                                        what is required here. */
    else if (   osTypeId == "MacOS108"
             || osTypeId == "MacOS108_64")
        uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure out
                                                                        what is required here. */
    else if (   osTypeId == "MacOS109"
             || osTypeId == "MacOS109_64")
        uMaxIntelFamilyModelStep = RT_MAKE_U32_FROM_U8(1, 23, 6, 0); /* Penryn / X5482 */ /** @todo figure
                                                                        out what is required here. */
    if (uMaxIntelFamilyModelStep != UINT32_MAX)
        InsertConfigInteger(pCPUM, "MaxIntelFamilyModelStep", uMaxIntelFamilyModelStep);
}
[/quote]

which pretty much, and in conjunction with your VBox.log, tells me that if you set the template to "OSX" your CPU is presented as a Xeon "Harpertown" X5482, whereas if you set the template to "OSX 10.10" your i5-7600 is presented unfiltered.

Apparently this needs to be updated. There's also a ticket, #13118: Presenting compatible CPU architecture to Mac OS X guest VMs, which was closed as obsolete (and which I just re-opened), both for your crash, and for the fact that if I don't set the following for my 10.5 and 10.6 clients, they crash as well. You might want to do the same for your 10.10 guest:

• 
  VBoxManage modifyvm "Mac OSX 10.6" --cpu-profile "Intel Core i7-6700K"
  

I might open a thread that summarizes the situation with different hardware/guest combinations. I'll let you know...

Mystery solved. Thanks for reopening the bug. Hopefully it will be fixed at some date.

I managed to get a hold of a couple of developers over IRC and here's the summary:

1. That part of the code is indeed what makes your guest work/crash depending on the template chosen. That piece of code is a "hack", at best.
2. The "--cpu-profile" is much more robust because it includes a complete profile of the CPU, not just the stepping family (that's the "hack" part). But the CPU profile was added at a much later time, most probably to address inefficiencies in the family model.
3. They know about it and they're thinking of the best forward-looking implementation. From exposing the CPU as a GUI option (my idea, really dangerous) to changing it depending on the template, to...

I would be happy with using --cpu-profile if I knew what the appropriate value is for each release of MacOS X, macOS. Possibly a table as an expansion of the documentation in Section 9 of the Help manual.

Or maybe thats what the effect of setting the OS version in system settings should be - i.e. don't just patch a few instructions but set the appropriate cpu-profile (but also continue to allow it be over-ridden through VBoxManage for the experimenters amongst us)

I'm glad to hear that the developers are looking at the issue and hopefully they will come up with a robust solution that takes into account these factors.