Fixed features, topology, clock, hpet, and cpu to host and qemucommandline settings

[Pavo-IM]

• Added feature to hide the hypervisor from macOS.
• Fixed topology to allow OpenCore to detect and report it correctly to macOS.
• Changed clock to localtime, so macOS will always be in sync with UnRAID's time.
• Changed HPET to be enabled in macOS (fixes some TSC Sync issues on AMD systems).
• Changed CPU type to host because naming CPU is not needed, plus only added the required CPU features and removed all others since passing through as host will pass through all other CPU features as well. This works for both AMD and Intel CPUs.

[Pavo-IM]

The hidden state=on is part of the hypervisor features which only hides it from MSR discovery. The reason you have to add kvm=on in the qemucommandline part is because anytime you change anything with the -cpu option it removes kvm as the hypervisor, which is why you have to tel qemu that it is using kvm as the hypervisor again.

Using host as the cpu type allows both Intel and AMD to pass through all their respected cpu features and use OpenCore to emulate a CPUID that macOS is expecting. Emulating at the boot loader level is better than trying to emulate at the hypervisor (hardware) level. Yes you can still emulate at the hypervisor level but you have to add every single cpu feature that whatever cpu name you use to the list of cpu features to pass through, where as emulating at the boot loader level allows all cpu features to be passed through and the OS decides which ones it will use or not.

machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH MMX FXSR SSE SSE2 HTT SSE3 PCLMULQDQ SSSE3 FMA CX16 SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES VMM XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET BMI1 AVX2 SMEP BMI2 RDSEED ADX SMAP CLFSOPT CLWB SHA UMIP RDPID STIBP ACAPMSR SSBD

[82ghost82]

Thank you very much for explaining. Sorry to insist, but still I'm not sure why we should need to hide it (in libvirt) and then show it again (in qemu args).

https://listman.redhat.com/archives/libvir-list/2014-August/msg00744.html

This means that kvm=off and hidden_state=on are the same: if we put hidden_state=on and kvm=on in the xml, kvm=on will be taken into account, in other words as not writing hidden_state=on.

If we put cpu host, what is the recommended settings for the smbios data in the config.plist, so I can eventually push a pr for it? It is now setup as automatic=true and processortype=0, I imagine processortype should be spoofed with cpu=host (I think this is what you replied to me in the forum)? Do you have any recommendation for a "universal value" for this modified xml so that the users don't have any panic/lock during boot?

[Pavo-IM]

Seems your information is correct on the hidden_state=on is the same as the -cpu option, my bad.

The recommended SMBIOS depends on the macOS version and GPU you are using, I have always used MacPro7,1 with AMD GPU since RX 480/580 and Catalina and above. Currently running Monterey and RX 6900 XT. But you should always use the PlatformInfo -> Automatic=true and PlatformInfo -> Generic -> ProcessorType value depends on how many cores you are giving the VM and if you are using RestrictEvents.kext or not. You can set it to 0 for auto detection but if you are using RestrictEvents.kext, you need to follow the guidelines for using that kext https://github.com/acidanthera/RestrictEvents/blob/8bd9b009807157736e889d896b9b60fd84a8041d/README.md?plain=1#L17.

I currently use RestrictEvents.kext and use a value of 3841 = 0x0F01 because I am using a AMD 3970X Threadripper cpu and using -cpu host and I wanted it to show as the processor inside System Profiler in macOS.

For AMD CPUs you can use the following universal emulated cpuid and mask in the Kernel -> Emulate -> Cpuid1Data 57060500 00000000 00000000 00000000 and for Kernel -> Emulate -> Cpuid1Mask FFFFFFFF 00000000 00000000 00000000 This will emulate a Intel Xeon W 3235 cpu. When using a Intel CPU, there is no need to use the emulate section but doing so doesn't effect it booting. Have tested this on Intel Haswell, Skylake and Coffeelake systems and Ryzen and Threadripper systems.

[matheustavaresdev]

@Pavo-IM I have tried creating an image from your branch, but I get

gtk-update-icon-cache: Failed to open file /usr/local/share/icons/hicolor/.icon-theme.cache : No such file or directory
error: command 'gtk-update-icon-cache' failed with exit status 1

When running docker build . from the root of it on unraid's own terminal. Any ideas?

[goncalofalcao]

since space invader (a great guy) hasn't had time to maintain MacInABox, can I suggest one of you create your own version?

Thank you for the work