ghost82 Posted May 16, 2021 Share Posted May 16, 2021 (edited) On 5/15/2021 at 11:00 PM, giganode said: My god...what a monster!! Yesterday I changed the hard drive configuration, switching from vdisk file on ssd to sata controller passthrough with the same ssd attached with mac os restored on it. Well, performances increase a lot..From 237/257 MB/s (write/read) to 422/495 MB/s (write/read) with blackmagik software. AmorphousDisk mark results follow: Looking more into details, I found that this is because the virtual sata controller for vdisks in mac os is seen as a generic AHCI controller running at only 1,5 gigabit, the marvell 88se9230 I'm passing through runs at 6 gigabit. Not sure if the emulated sata controller running at 1,5 gigabit is a limit of mac os or of qemu (in other words I don't know if in a windows or linux vm it runs at the same 1,5 gigabit speed), anyway if you have a spare sata controller running at higher speed it may worth to pass it through! --> see below comment by giganode --> low speed probably related to too much overhead through virtualized devices. Moreover I used to keep the bootloader in a separated img or qcow2 image file instead of on the mac os EFI partition, but it seems that trim/discard doesn't work with virtual sata and FAT32 on mac os, so if you keep writing and delete on the EFI image file the host doesn't sync the free space with the vm. Passing through the sata controller and moving the EFI to the EFI partition of mac os seems to overcome this issue, since the disk is no more seen by the host and all is managed by mac os. Edited May 23, 2021 by ghost82 Quote Link to comment
ghost82 Posted May 21, 2021 Share Posted May 21, 2021 (edited) On 4/28/2020 at 4:21 PM, ghost82 said: Maybe we first need to choose a smbios such that the original SystemProductName is equipped with an optical drive..I doubt it is going to work with a sata bluray/dvd writer if the original iMacPro1,1 has no optical drive..In this case, a sata to usb adapter could work.. And it works instead..ideally every sata cd/dvd/bluray should work. I'm currently using a teac bluray attached to the passed through sata controller. Not sure if it's possible to pass through directly the cd/dvd/bluray drive in libvirt, I tried in the past without success, but I think I didn't choose correctly the bus to attach it, attaching it to a virtual sata controller could work. Edited May 21, 2021 by ghost82 Quote Link to comment
ghost82 Posted May 21, 2021 Share Posted May 21, 2021 On 12/13/2020 at 9:54 PM, bjornatic said: I'm here for some help again... I passed through my Nvme and I finally put it on the right soket (the one wich support GEN 4 over chipset). The command : lspci -vvvn -s 04:00.0 | grep LnkSta results in : LnkSta: Speed 16GT/s (ok), Width x4 (ok) But, in System Report, I get a blank for the "link speed" information. After the install of BigSur, as my drive was on the first socket (GEN 3), "link speed" was 8GT/s (as it should have been). Now how do I get my drive at 16GT/s under Big Sur ? Not 100% sure on this, I'm replying only now because I'm playing with pcie slots, gpu and speeds. In my case, in system report for the gpu it reports always 2,5 GT/s, with gpu under load or not, the grep command reports 2,5 GT/s under no load, but 8 GT/s (GEN3) under load. This to say that if the grep command reports 16GT/s (GEN4) don't bother to system report, your nvme should work at the max speed. Quote Link to comment
bjornatic Posted May 22, 2021 Share Posted May 22, 2021 Unfortunatly, it does not... I should see close to double the speed... But it's not a real problem so It's quite low in my "solve the thing" list. 😑 Quote Link to comment
ghost82 Posted May 22, 2021 Share Posted May 22, 2021 2 minutes ago, bjornatic said: I should see close to double the speed... How are you passing through the nvme drive? by-id or pci passthrough? What brand is the nvme? Quote Link to comment
bjornatic Posted May 22, 2021 Share Posted May 22, 2021 (edited) Yes it's passed through. And its a SAMSUNG 980PRO. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> I read that the Samsung controller where tricky and not advised on a Hackintosh. But I found no specific info/comment on this one ("Elpis" controller). Edited May 22, 2021 by bjornatic additionnal infos Quote Link to comment
ghost82 Posted May 22, 2021 Share Posted May 22, 2021 (edited) The fact that you have an empty field for the GT/s instead of 16, makes me think that the os doesn't include yet the 16GT/s for nvme, I don't think a real mac has never been built with gen4 slot. Anyway I saw around builds with gen4 drives and speeds reaching about 4 GB/s (most are 1 TB and different than samsung). May be related to the os (or the drive?), but I'm not 100% sure. The advice on samsung controllers should be related to older ones, I think it's correct to avoid samsung, however if you don't have kernel panics it means yours should work quite well (?). No doubt speed is slow if it fits a gen4 slot, if the bios settings are correct and if you placed devices in correct slots so to not eventually cut the bandwidth. Edited May 22, 2021 by ghost82 Quote Link to comment
giganode Posted May 22, 2021 Share Posted May 22, 2021 (edited) On 5/16/2021 at 11:02 AM, ghost82 said: My god...what a monster!! Yesterday I changed the hard drive configuration, switching from vdisk file on ssd to sata controller passthrough with the same ssd attached with mac os restored on it. Well, performances increase a lot..From 237/257 MB/s (write/read) to 422/495 MB/s (write/read) with blackmagik software. AmorphousDisk mark results follow: Looking more into details, I found that this is because the virtual sata controller for vdisks in mac os is seen as a generic AHCI controller running at only 1,5 gigabit, the marvell 88se9230 I'm passing through runs at 6 gigabit. Not sure if the emulated sata controller running at 1,5 gigabit is a limit of mac os or of qemu (in other words I don't know if in a windows or linux vm it runs at the same 1,5 gigabit speed), anyway if you have a spare sata controller running at higher speed it may worth to pass it through! Moreover I used to keep the bootloader in a separated img or qcow2 image file instead of on the mac os EFI partition, but it seems that trim/discard doesn't work with virtual sata and FAT32 on mac os, so if you keep writing and delete on the EFI image file the host doesn't sync the free space with the vm. Passing through the sata controller and moving the EFI to the EFI partition of mac os seems to overcome this issue, since the disk is no more seen by the host and all is managed by mac os. Hi @ghost82... The 1,5 Gbit indicated in the system overview of macOS are not relevant. Here is a benchmark with my image, stored on an nvme: Edited May 22, 2021 by giganode 1 Quote Link to comment
ghost82 Posted May 28, 2021 Share Posted May 28, 2021 Anyone passing through a firewire controller? I don't have any device to test, I'm not sure it works, in about this mac --> system report --> firewire, I read: Firewire bus Warning: unable to list firewire devices It's a VIA VT6315 chipset, firewire 400, from the boot log it seems correctly initialized. In my original macbook pro, there's no device attached but I can read the bus speed instead of the warning; however in that macbook pro the isight should be connected to the firewire bus internally. Quote Link to comment
ghost82 Posted May 29, 2021 Share Posted May 29, 2021 This: may be useful to understand how the q35 emulated machine topology works, so that we can attach hardware in the correct bus, for example HDEF audio and built-in ethernet. 1 Quote Link to comment
ghost82 Posted May 30, 2021 Share Posted May 30, 2021 Latest release of OVMF_CODE.fd and OVMF_VARS.fd from edk2, v. 202105 (2021-05-28). Compiled in kali linux with gcc, tested and working. edk2-OVMF-202105-Stable-RELEASE.zip 1 Quote Link to comment
david279 Posted June 7, 2021 Share Posted June 7, 2021 Time to get it cooking again...Monterey dev 1 1 Quote Link to comment
david279 Posted June 7, 2021 Share Posted June 7, 2021 Simple install with any recently updated version of opencore. I hear bluetooth breaks boot on bare metal so i would avoid that. Im using virtio for the network and the disk type and it boots just fine. Now to see what does not work. 1 1 Quote Link to comment
ghost82 Posted June 8, 2021 Share Posted June 8, 2021 (edited) 7 hours ago, david279 said: Simple install with any recently updated version of opencore Hi, I had no doubt, I saw yesterday the presentation at wwdc and apart xcode cloud and universal control (which I don't use) there's nothing new (and so I imagine the boot has the same logic of big sur)..No need for an entire os update if this is what apple presents..So apart a recompilation of all the basic kexts just to add the new kernel version number, no particular changes are needed. Hopefully since they didn't improve anything they had time to fix the ton of bugs still there in big sur. Edited June 8, 2021 by ghost82 Quote Link to comment
glennv Posted June 9, 2021 Share Posted June 9, 2021 (edited) On 6/8/2021 at 1:00 AM, david279 said: Simple install with any recently updated version of opencore. I hear bluetooth breaks boot on bare metal so i would avoid that. Im using virtio for the network and the disk type and it boots just fine. Now to see what does not work. Mind sharing your (neutralised) EFI ? Have Big Sur running fine but after update it does not boot (kp's) . Did update lilu/weg etc before (and did set -lilubetaall ), but something is off . Probably too old OC or something. edit : updated tp OC 0.7.0 but still same . Boots fine in BigSur but not in the Monterey mode. edit2 : came a bit further. Found that kernel patches where limited by the set max release value (20.99.99) , changing that to 21.99.99 moved the boot process further. Still crashing at the end in a boot loop with mentions of SMC issue but out of time this week to investigate further. Will have to settle for patience Edited June 9, 2021 by glennv Quote Link to comment
david279 Posted June 9, 2021 Share Posted June 9, 2021 5 hours ago, glennv said: Mind sharing your (neutralised) EFI ? Have Big Sur running fine but after update it does not boot (kp's) . Did update lilu/weg etc before (and did set -lilubetaall ), but something is off . Probably too old OC or something. edit : updated tp OC 0.7.0 but still same . Boots fine in BigSur but not in the Monterey mode. I have -lilubetaall in the boot args thats the only thing i added there. The OC im using is 0.6.3 version for the VM. My laptop running Monterey is on 0.6.9 with pretty much the same boot args and all my kext were update as of the yesterday. I will say i have a bug where it boot loops on VNC for some reason. Passing thru a gpu maybe more stable. Quote Link to comment
glennv Posted June 9, 2021 Share Posted June 9, 2021 (edited) Maybe we hit the same VNC bootloop then , who knows My GPU is in use for a while in a productive VM so cant test that. Some other time... Edited June 9, 2021 by glennv Quote Link to comment
glennv Posted June 9, 2021 Share Posted June 9, 2021 (edited) Ah , just when i wanted to call it a day, it started working Issue was related to me using/trying to boot from an earlier created Monterey update partition, before i messed with opencore/nvram clearing etc etc when booting in the BigSur partition. So likely not valid anymore (nvram, seal , stuff like that) . I just booted in BigSur again and re-ran the updater, which recreated that partition and voila. Update is running fine now and no boot issues. The real issue in "my" opencore config was as i mentioned the max value limit (minkernel/maxkernel) on the kernel patches. The rest was noise . Likely would have also worked on my original pre 0.7 version. Edit : upgrade finished and entered into a screen loop (vnc) like you mentioned experiencing as well (see screenshot of looping 4 lines). Will try it some other day on GPU. I can dial into the VM via SSH , which works fine. Edit 2: Did a quick try with GPU to satisfy my curiosity (5700XT). Did get a black screen (but that can be something else) , but i could use RDP to dial in and proved it works. Just no VNC (looping. Login windows crashed. ssh works). So almost but no sigar yet Edited June 9, 2021 by glennv Quote Link to comment
RiDDiX Posted June 9, 2021 Share Posted June 9, 2021 I got my Big Sur just updated fine to Monterey. Just it feels a lil bit laggy.. OK Beta And yes Bluetooth doenst work atm. Which maybe is a dealbraker for someone (it will include me if this doenst get fixed in a few weeks/days) Quote Link to comment
ghost82 Posted June 10, 2021 Share Posted June 10, 2021 (edited) Sharing my theme BigSurFlat for opencanopy, works with latest oc/ocbinarydata versions. Available on github: https://github.com/82ghost82/BigSurFlat Edited June 21, 2021 by ghost82 1 Quote Link to comment
glennv Posted June 11, 2021 Share Posted June 11, 2021 On 6/9/2021 at 3:46 PM, glennv said: Maybe we hit the same VNC bootloop then , who knows Solved the mysterous VNC bootloop issue. 1. Log in with a GPU passed thru (i used RDP as my GPU showed black at the time) 2. Set autologin in user options (seems to be an issue with login process looping in some cases) 3. Reboot without GPU passed thru and now VNC works fine. Quote Link to comment
RiDDiX Posted June 11, 2021 Share Posted June 11, 2021 4 hours ago, glennv said: Solved the mysterous VNC bootloop issue. 1. Log in with a GPU passed thru (i used RDP as my GPU showed black at the time) 2. Set autologin in user options (seems to be an issue with login process looping in some cases) 3. Reboot without GPU passed thru and now VNC works fine. Do you also experience some laggs within a few seconds? It seems fluid but nearly every 5 seconds its get laggy, but immideatly back to normal, then again a short lagg and back to normal XD Maybe I revert back to Big Sur Quote Link to comment
glennv Posted June 11, 2021 Share Posted June 11, 2021 (edited) 1 hour ago, RiDDiX said: Do you also experience some laggs within a few seconds? It seems fluid but nearly every 5 seconds its get laggy, but immideatly back to normal, then again a short lagg and back to normal XD Maybe I revert back to Big Sur Nope cant say i have that. Seems all fluid. Did a quick performance test with Davinci Resolve and the passed thru 5700XT and seems exactly the same or even slightly faster than my normal production Resolve Render VM on Catalina. Have not spend much time with it yet. Just for base testing my own code against he new OS , but as little seems to have changed compared to BigSur all is fine there. I remember from my old Windows 10 VM's when i used them for gaming i did have these stutters , but typicaly where related to passed thru usb and or network polling latency issues. On OSX i have not seen this yet. But then again currently i have no USB card yet passed thru to this test VM. If i notice anything in the coming days i will let you know. Probably best to wait for the next beta anyway. Also i run Intel and you Ryzen so check for Ryzen related issues. I do remember seeing some reddit posts on Ryzen patches. Edited June 11, 2021 by glennv Quote Link to comment
ghost82 Posted July 15, 2021 Share Posted July 15, 2021 (edited) For who is using the x86_validate_topology patch, there's a new patch that covers a wider range of kernels (I remember I had to change this patch from Mojave to Catalina and to Big Sur). This is the new patch, should be valid for mac os monterey too: <dict> <key>Arch</key> <string>x86_64</string> <key>Base</key> <string>_x86_validate_topology</string> <key>Comment</key> <string>XLNC - Disable _x86_validate_topology - 10.13/10.14/10.15/11.0/12.0</string> <key>Count</key> <integer>0</integer> <key>Enabled</key> <true/> <key>Find</key> <data> </data> <key>Identifier</key> <string>kernel</string> <key>Limit</key> <integer>0</integer> <key>Mask</key> <data> </data> <key>MaxKernel</key> <string>21.99.99</string> <key>MinKernel</key> <string>17.0.0</string> <key>Replace</key> <data> ww== </data> <key>ReplaceMask</key> <data> </data> <key>Skip</key> <integer>0</integer> </dict> Also, the force penryn patch was recently modified to be compatible from big sur 11.3+ till monterey, for big sur 11.3+/Monterey 12: <dict> <key>Arch</key> <string>x86_64</string> <key>Base</key> <string>_cpuid_set_info </string> <key>Comment</key> <string>algrey - _cpuid_set_cpufamily - Force CPUFAMILY_INTEL_PENRYN - 11.3 + / 12.0</string> <key>Count</key> <integer>1</integer> <key>Enabled</key> <true/> <key>Find</key> <data> gD0AAAAABnU= </data> <key>Identifier</key> <string>kernel</string> <key>Limit</key> <integer>0</integer> <key>Mask</key> <data> //8AAAAA//8= </data> <key>MaxKernel</key> <string>21.99.99</string> <key>MinKernel</key> <string>20.4.0</string> <key>Replace</key> <data> urxP6ngx2+s= </data> <key>ReplaceMask</key> <data> </data> <key>Skip</key> <integer>0</integer> </dict> Edited July 19, 2021 by ghost82 1 Quote Link to comment
ghost82 Posted July 18, 2021 Share Posted July 18, 2021 (edited) Commit 9324c9e: https://github.com/acidanthera/OpenCorePkg/commit/9324c9e32c8b1cb714f2869b4fdde72f92d58bf4 in opencore 0.7.2 increases the default MinDate and MinVersion of APFS driver date/version to that of Big Sur. If you have default values of MinDate and MinVersion (equal to integer=0) in your config.plist, you are running an os older than big sur and you updated opencore to a version equal or subsequent to that commit, you need to either disable, setting MinDate and MinVersion to -1 (integer) (not recommended), or manually set MinDate and MinVersion in the config.plist. For example, if you're running Catalina, with MinDate and MinVersion equal to zero, you will not be able to boot, since the minimum date/version of the apfs driver is that of big sur. To boot Catalina (at least 10.15.4) you need to set these values in the apfs section of the config.plist: <key>MinDate</key> <integer>20200306</integer> <key>MinVersion</key> <integer>1412101001000000</integer> Other values: High Sierra (10.13.6 - 17G12034) MinDate: 20180621 MinVersion: 748077008000000 Mojave (10.14.6 - 18G4032) MinDate: 20190820 MinVersion: 945275007000000 Edited July 18, 2021 by ghost82 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.