Proxmox VE OSX Guide discussion

[fabiosun]

@Driftwood I have said to Pavo all I did in discord message

i use the same my config for all OS X 

no osk

host on both args and vm device 

060 opencore version you can download it with Vm assistant -doc

nothing more

[Rox67er]

On 7/12/2020 at 2:44 AM, iGPU said:

This post raises 2 issues: Cinebench 20 speed in Catalina vs Big Sur (trivial), and 'host' vs 'Penryn'.

 

***

 

I'm presently running Big Sur under 'Penryn' VM setting (since I cannot yet get 'host' to boot), while previously, Catalina was run under 'host' VM setting. When testing Cinebench 20, the score in Big Sur is about 500 lower than I was seeing in Catalina.

 

So to keep things equal, I used the same VM and EFI settings for Big Sur to boot into Catalina. When I run Cinebench 20 under these conditions, I again get a 500 greater score in Catalina (17700 to 17800) than in Big Sur (17200 to 17300). I ran these tests several times over several boots.

 

So while Cinebench 20 is (presently) slightly slower under Big Sur, the 'Penryn' setting does not run any slower than 'host' with Catalina.

 

***

 

The above similarity in speed in Catalina when running under either 'host' or 'Penryn', makes me wonder how significant is either setting in our VM. I've read such statements as those below, which doesn't clearly indicate one being necessarily superior to the other:

 

"For homogeneous clusters and single host setups, use the 'host' option. For mixed clusters, use the lowest available CPU version, so if one host is Penryn and the other Nehalem, use Penrym on both."

 

"The 'host' option is good, but not the most efficient because it might enable options that can be emulated but that your cpu does not support. The guest system can then be slowed down anytime it tries to use one of those features that needs emulation."

 

Supposedly, to see the differences between the host and the guest, one can type:  grep flags /proc/cpuinfo | uniq, which gives on my system:

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca

 

But my VM for the guest has these arguments:

-cpu Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,check

 

I don't understand how the above command lists unique items, since many are in common to both host and guest, such as: aes, avx, avx2, bmi1, bmi2, popcnt, xsave, xsaveopt (assuming that the VM properly used the argument flags for the guest).

@iGPU Be aware that the kernel patches section (in OC) play an important role in being able to set "host" as cpu. I have these two active and I'm pretty sure if I leave them out also Catalina won't boot with "host" setting.

 

[fabiosun]

@Rox67er if our trx40 could boot without those kernel patches with host...we had had aN Apple supported chip in our rig😊😊

More than vanilla I mean😂

[Driftwood]

I use host for Catalina no problem with minimal args. 

Edited July 14, 2020 by Driftwood

[iGPU]

17 hours ago, Rox67er said:

@iGPU Be aware that the kernel patches section (in OC) play an important role in being able to set "host" as cpu. I have these two active and I'm pretty sure if I leave them out also Catalina won't boot with "host" setting.

 

 

Enabling those 2 patches, still does not allow me to boot in BS as 'host'. I can boot into BS with both enabled or disabled as 'Penryn'.

 

Using the same settings, and having those 2 patches enabled and using 'host', I can boot into Catalina (but, again, not BS).

Edited July 15, 2020 by iGPU

[Rox67er]

3 hours ago, iGPU said:

 

Enabling those 2 patches, still does not allow me to boot in BS as 'host'. I can boot into BS with both enabled or disabled as 'Penryn'.

 

Using the same settings, and having those 2 patches enabled and using 'host', I can boot into Catalina (but, again, not BS).

I didn't experiment with Big Sur yet but are the patches still the same for the new kernel?

 

Found this on Nick Sherlock's Big Sur page, seems to confirm my statement:

"The CPU is set to pretend to be Penryn, because the macOS kernel patch that would support -cpu host has not yet been ported to Big Sur. Ensure the args are all on a single line!"

Edited July 15, 2020 by Rox67er

[fabiosun]

5 hours ago, Rox67er said:

I didn't experiment with Big Sur yet but are the patches still the same for the new kernel?

 

Found this on Nick Sherlock's Big Sur page, seems to confirm my statement:

"The CPU is set to pretend to be Penryn, because the macOS kernel patch that would support -cpu host has not yet been ported to Big Sur. Ensure the args are all on a single line!"

Then I will do a video to prove that in my system Big Sur starts with host in vm with latest oc

then if you say to nick I hope he will give proper credits this time 😜

[fabiosun]

 

[iGPU]

8 hours ago, fabiosun said:

Then I will do a video to prove that in my system Big Sur starts with host in vm with latest oc

then if you say to nick I hope he will give proper credits this time 😜

 

I will re-test later tonight after work, using: "args: -smbios type=2 -cpu host,vendor=GenuineIntel,+invtsc" in VM. This is much abbreviated than the one I'm presently using (which I posted a few threads ago). There is also one other patch I've used, making a total of 3, and I'll try the various combinations when using 'host'.

 

Also, I just realized that in the patches section, the "MaxKernel" was set to 19.99.99 which does not include Big Sur, so perhaps none of these were even loading when I did the test last night (mentioned above). Best to leave this section blank, as the exact numbering of Big Sur is not clear (v 11 or 10.16.0; if 10.16.0 is used by Apple, then MaxKernel would become 20.00.0, or better, 20.99.99).

 

 

***

 

ADDENDUM:

I had time to run 2 tests using brief arg list in VM and cpu set as 'host'.

 

Referencing the kernel patch list above (with MaxKernel = blank):

  A) #1 and #2 enabled --> no boot

  B) #1 and #3 enabled --> no boot

Edited July 15, 2020 by iGPU

[fabiosun]

Yep no need of  third patch for us

only the numbers for Big Sur version and old two patches In config.plist file

 

[fabiosun]

@iGPU

a verbose boot said something?

[Driftwood]

Surely if we use FORCE_CPUFAMILY_INTEL_PENRYN argument in OC then we're still using Penryn!?

 

It looks like its a problem with our Radeons. Having discussed with @fabiosun on Discord - he has yet to trial AMD GPU Radeon...which I await with anticipation! - the common denominator is that the rest of us are all using Radeon VII. 

 

I hope to be proved wrong!

Edited July 15, 2020 by Driftwood

[fabiosun]

hi @Driftwood

I do not know if it is related to radeon (maybe connected also to reset bug??) or bios different settings of AsRock and Gigabyte mb (which seem to have the chance to go deeper than MSI during settings cpu and others parameter)

 

I can only say that I use a single VM config file to boot High Sierra, Mojave, Catalina and latest Big Sur Beta 2.

Also my EFi is the same for all (one EFI allows to boot properly in all system above)

In OSX above High Sierra I have limitation you know because I have no GPU driver for them

It would be interesting if other users with MSI or Asus board have the same problem or not

 

[Driftwood]

2 hours ago, iGPU said:

args: -smbios type=2 -cpu host,vendor=GenuineIntel,+invtsc"

Tried that to no avail over the last few days..! Fail

 

Tried so many variables changing just one at a time and reboot!

Edited July 15, 2020 by Driftwood

[Ploddles]

I am just about to embark on the ThreadRipper/macOS journey. I have bits on order and am awaiting delivery but I have 34 pages of this thread to read first.

 

I know absolutely nothing about Proxmox so this will be an 'interesting journey' and who knows, by xmas I may have a working (Mac) system 🙂

 

I have a Gigabyte motherboard and the 3960x on order. Hopefully this will be a good combination for my Hackintosh. My 'old' i9-9900k Hack will be going to my daughter for her university degree work in Digital Animation. Building that has at least educated me a little in hackintoshing. Wish me luck 🙂

 

[fabiosun]

@Ploddleswelcome 😊

evaluate well 3960x

some user said it is difficult to pass all cores in proxmox

i have no direct experience on this

witn 3970x I can use all its cores

[Ploddles]

2 hours ago, fabiosun said:

@Ploddleswelcome 😊

evaluate well 3960x

some user said it is difficult to pass all cores in proxmox

i have no direct experience on this

witn 3970x I can use all its cores

 

Thanks for letting me know so quickly. I have now changed my order to the 3970x.

[iGPU]

I went through the various patches; no combination allows me to boot into Big Sur ß2 using 'host'. When using 'Penryn', booting and behavior seems the same whether the patches are enabled or disabled. I also tested with the briefer VM arg list and the longer list; again, behavior seems about the same either way. Meanwhile, booting in Catalina is easily done with either 'host' or 'Penryn'.

 

The difference in GPUs might influence the host/Penryn problem. I ran a few tests, re-affirming some findings from a couple of months ago, using Radeon VII.

 

First, I don't see reliable GPU function as pass-through unless 'amdgpu' is blacklisted. Example: booting into Catalina without blacklisting 'amdgpu', shows only a black background (icons and functionality are okay, but newly opened windows are laggy to display items). After 3 minutes or so, the normal Catalina background image suddenly appears. This behavior is independent of using WEG. If 'amdgpu' is then blacklisted and Proxmox re-booted, then when booting into Catalina, the background image is normally displayed and windows work well. Therefore, 'amdgpu' should be blacklisted in Proxmox for good Radeon VII behavior.

 

With Big Sur, if 'amdgpu' is not blacklisted, I cannot boot into Big Sur; 'amdgpu' blacklisting is essential for Big Sur (at least thru ß2) with Radeon VII. So there is a difference in GPU behavior and 'amdgpu' blacklisting between Catalina and Big Sur. (And I think the 'amdgpu' issue is different between my system and yours, fabiosun, in spite of our both using MSI mobos.)

Edited July 16, 2020 by iGPU

[fabiosun]

you're making me want to buy a Radeon VII again 🙂 🙂

 

[iGPU]

I got VM 'host' to boot in Big Sur (even with Radeon VII), but...

 

First, I removed all boot arguments in OC except for -v. I did have Kernel patches #1 and #2 (Penryn) enabled (from previous post).

 

Then during first reboot, before changing VM from 'Penryn' to 'host', I did a 'Reset NVRAM' within the OC boot menu (I think this step was key). Screen stayed black at this point, so I turned off computer, restarted and once logged into Proxmox, I changed the VM to 'host'. The VM arg is the long one previously listed (except using 'host').

 

I then started the VM and all booted just fine into Big Sur.

 

However, when I changed Kernel Patch from the #1 and #2 combination to #1 and #3 (leaf7), Big Sur would not boot, but froze at screen shot shown below:

 

Edited July 17, 2020 by iGPU

[fabiosun]

Ok

i can wait for real big Navi then 😊

[fabiosun]

In the stage of your latest and initial hang as you show in screen capture do you have vsmcgen =1 in your config?

[iGPU]

8 hours ago, fabiosun said:

In the stage of your latest and initial hang as you show in screen capture do you have vsmcgen =1 in your config?

 

No, only "-v". I'm using latest commit: v060 dated 14 July.

Edited July 17, 2020 by iGPU

[fabiosun]

@iGPU also with latest kext (lilu) And drivers?
if so it is weird

yesterday I have reinstalled from high Sierra latest b2 and I have had success with my old 060 Efi with host in Vm 

you can also try with:

AvoidRuntimeDefrag = NO if you have it previously to YES

 

Gigabyte has updated Designare bios to Agesa 1.0.0.4?

[fabiosun]

 

High Sierra and web drivers updated to latest security fix