Leoyzen

@subivoodoo I will try when I get time, maybe this weekends.

@david279Yeah, I don't test the performance diff yet, but I heard you can chang to 15/16th config to get improvement.

@Young_MaxThe log is normal. Just add latest Lilu and WEG to make your graphic work, there is no relation between "pci=noaer" and your black screen. You can read this post first.

@Young_Max Benchmark yourself to see the difference. I have no idea how much it is.

@Young_Max see here

@Young_Max Do you use x570 and zen2?Do you put your AMD card in second pci-e slot? If so, add pci=noaer in your boot args or try move the graphic to the first slot.

@david279 <qemu:arg value='host,kvm=on,+invtsc,+hypervisor'/> is enough, there is no more need other features specification.

@ClintWilkensonread the section 2.1,2.2 and 4 to get your audio work. https://forums.unraid.net/topic/84430-hackintosh-tips-to-make-a-bare-metal-macos/

Not now.I don't find a way to expose kvm in libvirt, I may submit a bug report when I got time.

You can't remove qemu custom cpu args.'kvm=on' and 'invtsch must be passed in this way, it is a QEMU bug. without this MacOS and opencore won't get TSC frequency correctly.

The Lilu 1.3.9 officially released now, check the link again and update it. Remember to remove all the grahpics patches.

The lastest opencore release(0.5.2) works properly with virtualization(topology support and more accurate frequency reading from new cpuid leaf) and amd(you can just passthrough now with amd vanilla patches), can be downloaded from here now. Also the Lilu officially released too(1.3.9) which add QEMU support, finally we can use Lilu/WEG/AppleALC in Hackintosh VM now. Can be downloaded from here. Recommand to update them all. cheers!

I'm trying to say, there should not using qemu custom args, we should just set the cpu info as windows or other vm by libvirt.But this bug let it not happend.The simpler the better，right？Everything that make hackintosh VM not like others may be a bug or compatibility problem, we should just pay attention to it. Yeah,obviously the performance will be dedicated disk(NVME/SSD) > raw format vdisk > qcow2 pre-allocated vdisk> qcow2 sparse vdisk. What ever which type you choose, there will be 3%~5% performance reduction compared to bare metal due to vfio. I'm passing through my nvme as the hackintosh disk now.

I've found another QEMUbug. According to the source code of QEMU, "kvm=on" should be default set to "on" when using a X86 CPU Model, but it is not! Libvirt can't set "kvm=on" at all, we must use "qemu custom args" to make it happen.

Yeah, that's alright. Good to see there is an other information update of Hackintosh VM😁 Yeah it is truely a important notes I've found but rarely be heard in the internet. Thanks for the feedback!

@databaselandI did not seeing that you passthrough the graphic audio with the gfx. And does metal work? Which version of Liu/WEG do you use? 1. passthrough all the part of the graphics(gfx, audio, usb) and set the bus correctly in the xml 2. use iMacPro instead of MacPro7,1 3. remove "Fix Display" and other patch which related to the graphic use the Liu I post and the latest WEG then try again.

This is a bug of clover and opencore. I just working on a pull-request to add QEMU/KVM support in opencore, links here. Also, the cpuid feature 'hypervisor' should be exposed too to get proper handles. You didn't set the gpu gfx and audio in same bus, that causes some problem. Should be set like this. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/XFX.RX580.8192.170323.rom'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x09' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </hostdev> Also, you should put latest Lilu(1.3.9) and WEG/AppleALC to your clover kext folder to avoid black screen. There is a commit which add QEMU support in latest Lilu, the older version not work on QEMU at all. You can custom build the Lilu or download from this post. https://forums.unraid.net/topic/50191-video-guide-how-to-install-macos-mojave-or-high-sierra-as-a-vm/?do=findComment&comment=781179

@ghost82 did you put -v in your boot args to see what the error is? I'm on 19A602 with clover and the patch works for me. I don't set it in qemu extra args but livirt topology defination, like this: <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> <feature policy='require' name='topoext'/> </cpu> I'm not upgrading yet so I'm not quite sure about then problem you say.

I demonstrated that I change the QEMU smp(which equal to topology defination in libvirt/xml) between those three tests. If not, how should I change the topology? As far as I know, I don't see a way to change the topology in a bootloader, mind tell me how? Let me quote the conclusion you've made in your thread which I'm argued: The test I've made just demonstrated that "There is no performance difference between declare a topology with/without hyper-threading defination, even with no topology defined at all.", at least it is outdated now.

As I mentioned, I don't see any performance reduction before, to prove that, I just did some test to indicate the conclusion you've made is outdated now. VM CPU: 4-7, 12-15, which 4 cores and 8 threads VM OS: Catalina 10.15 (which is as clean as possible, only benchmark softwares) VM Bootloader: opencore with modified to get correct FSBFrequency and Topology (from here) Benchmark software: Cinabench 20 and Geekbench 5 CPU Model: IvyBridge with all features that host supported Results: 4 cores and 8 threads with SMP topology Cinabench: 2554 Geekbench: 1273(S)/5455(M) 8 cores with SMP topology (which MacOS recognized as 8 cores) Cinabench: 2551 Geekbench: 1277(S)/5433(M) 8 cores without SMP topology (which MacOS recognized as 8 sockets, I don't know if there any differences) Cinabench: 2546 Geekbench: 1279(S)/5387(M) Conclusion: I don't see any performance reduction between SMP using and not using hyper-threading during my test. I'm not saying you did things wrong, it may just outdated or apple changes their codes. My point is I won't just buyin someones' conclusion which is rather old from now. It didn't make sense to me, if I fool the MacOS that it is not a thread but a core then there will get some performance gain?On the contrary, performance reduction makes more senses to me. Because it didn't change the fact it is actually a thread, its performance limit by the hardware anyway. Host: VM CPU pins: CPU features: <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='-cpu'/> <qemu:arg value='IvyBridge,vendor=GenuineIntel,+hypervisor,-erms,+invtsc,kvm=on,+topoext,+svm,+invtsc,+fma,+mmxext,+avx,+avx2,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+sse4a,+bmi1,+bmi2,+arat,+abm,+3dnowprefetch,+adx,+clflushopt,+cr8legacy,+fsgsbase,+fxsr_opt,+misalignsse,+movbe,+osvw,+pclmuldq,+pdpe1gb,+rdrand,+rdseed,+rdtscp,+sha-ni,+smap,+smep,+svm,+vme,+xgetbv1,+xsave,+xsavec,+clwb,+umip,+topoext,+perfctr-core,+amd-ssbd,+wbnoinvd'/> <qemu:arg value='-overcommit'/> <qemu:arg value='cpu-pm=on'/> </qemu:commandline> Cinabench screenshots: Geekbench Screenshots:

I read it before, but I have some reason to do so: 1. "what is the difference between vm and bare metal?" is the keypoint and I am trying to figure it out. There definately something wrong in clover and opencore which makes qemu/kvm incompatitable, so I'm trying figure it out. "Do things right" is my goal, I try to make vm as bare metal AMAP, so I'm digging every detail that different from bare metal hackintosh. The point is not performance, but we can't use smp, then QEMU simulate 8 sockets instead of 8 cores for us.I don't know if MacOS handles it well or there is performance impact but I'm trying to do the right thing. 2. It is quite old from now so I'm not believe it. There are many outdated tutorials in the net tell us to do this do that, but I found much of if useless by spending a lot of time, and there are little imformation tells about why doing this, why doing that, that's what I'm doing now. So if it is a thread lately, I may convinced by it. 3. I'm not buyin the conclusion. As a software engineer, I can't image that enable hyper-threading is worse than simulate cores.That does'nt make sense to me, there maybe something buggy in clover or opencore or other things.And as far as I tested, I can't find any performance reduction between those two. There is a way to enable smp/topology in current opencore or clover, just add this patch:

I found out that why we can't use topology line (equals to QEMU smp) uppon Penryn. When using Penryn, clover or opencore will lookup the topology from cpuid which is correct; but we using newer cpu model, clover or opencore will check msr 0x35 which qemu/kvm not implemented yet then we get wrong cpu topology (1 core 1 thread) then the kernel panic occured. Here is the details.

I've give out the steps to make virtio work but it still buggy and I make no progress there.Here is the link I've made looking for help but nobody response. I'm not facing the "e1000-82545em" problem which work for me all the time so maybe there is something/tips we are missing, but in my hackintosh vm, I've already change to passthrough a X550 nic instead.

@phbigred As far as I know there isn't any change beyond the pci reset bug, I just add one commit in latest rc builds. But I may lost some third party drivers which not included in kernel source but added by limetech (I'm not look into it). @MortalMonkeyGlad to hear that.

@calebcoverdale Maybe isolate 1~2 cores to handle IO, and add these thread in your xml as iothread, search for more details.