-
-
Notifications
You must be signed in to change notification settings - Fork 857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not work if passed through to a VM #291
Comments
Greetings. It seems like this is the first issue you open on this repository. We are letting you know that these are for bug reports or feature requests. Most of the reports we receive in this GitHub Organisation are user errors. For the sake of saving time, here are the most common cases:
We will never support the use of configurator software, solutions like This issue will be looked over by the respective maintainer when they can. In the meantime, look if you can resolve this yourself via checking the above. Be patient, we are hobbyists. |
might be the same as #235 |
It might, but #235 mentions crashes, while system is properly booted. Mine, in contrast, doesn't boot at all |
Nah. I think even Linux has trouble with AMD iGPUs being passed through to it. Or at least it did in the past. I would suggest waiting a little bit as I'm working on a semi-big bug fix and rewrite commit. |
The changes in question has been pushed. Let's see if it is fixed. |
Nope, still stuck at the exact same place with reboot |
Well, when it gets stuck here, it means it can't get the VBIOS. Perhaps you need to inject your system's VFCT ACPI table into the VM somehow. |
The VFCT table couldn't be injected, it's too big for QEMU. vfio-pci's romfile option also doesn't work. However, I can dump the VBIOS from my host OS and get a file with it - is there a way to load VBIOS from file instead of ACPI? EDIT: dumped the ACPI with dGPU detached, now it passes the size requirement and injects, but no luck here |
yes inject ATY,bin_image by using opencore device properties. you can get the dump from linux but i dont remenber exactly how |
Probably should not instruct him to rebuild the entire kext. Just use OpenCore's DeviceProperties method. |
Wow, guys, you rock! I did some changes to PCI QEMU settings and injected the VBIOS - and it works!
I wonder if these are the easy fixes, but if not, I'm fine with this - fully covers my use-case |
My MB died, so I was forced to buy a new one, and it's doesn't play well with macOS. I get a hard host reboot (not even a kernel panic) every time I turn my VM on. This isn't a VBIOS issue, probably - I have extracted a new one. No displays are plugged into the iGPU. Once again, if this is easily fixable - I'm all ears, otherwise feel free to close the issue, because this is becoming more about my problems than the kext ones. |
Maybe this is a bit late, you need to remove the vmware vga when you passhtrough the igpu. I had the same problem but under proxmox, but should be similar since it uses kvm as well. |
But how can I debug the boot process without the virtual display? With virtual display and physical display connected the system still reboots. |
you can add a serial device and send its output to a file |
Please check whether the virtual machine has the following configuration.
After all these settings are completed, it should be able to start normally. However, it should be noted that the restart of the virtual machine will be stuck because the integrated graphics hardware cannot be automatically reset. It can only be restored by restarting Proxmox VE. There may be a solution later. |
Yeah, I've set up my IOMMU groups with Zen kernel and ACS override patch. VBIOS isn't an issue, I'm passing it to the GPU by injecting it with device properties. GPU is also on the PCI.0 bus. I'm a bit puzzled that it worked for a moment, but doesn't work with another MB and another (but same model) CPU. Still setting up the debug environment, though, will be back later with serial logs |
My boot log via serial output (set it up with the instruction here). Looks like a lot is missing, am I doing it properly? Boot log
|
Hey @Myp3a, can you retry with the latest commit using the romfile method? NootedRed should now be able to read it in theory. |
Still breaks at the same place with no additional logging. I've tried the old Inject method and the new one, with Relevant QEMU config lines:
|
@Myp3a Try adding |
Done, now it looks like a proper log. Attaching it to the message below. Boot log
|
There's no logs about patches being done at all. Is Lilu even working? 😄 |
I'm pretty sure that it should work: it's defined in OpenCore and located in Kexts directory. However, I've updated it to the latest 1.6.9-debug and enabled logging. Logs w/ Lilu
|
That’s a bit better, still not useful though. I’m not sure what’s going on here, I’d suggest reconfiguring the EFI as per https://chefkissinc.github.io/guides/hackintosh and seeing if the behaviour changes afterwards. |
I think I have a clue: my log starts with But if I'm adding a QEMU VGA display, everything starts to work - NootedRed loads and patches proper values. However, system is thrown into a reboot afterwards, so we're back at square one. It recognizes the videocard, gets VBIOS and probably behaves as expected. VBIOS is probably fine - if I try other's people VBIOS, system breaks even earlier. My boot log with VGA attached
|
Honestly it seems like a Lilu issue to me. I think it only starts patching when the (vesa) display is initialised |
@Myp3a., Have you tried doing igpu passthrough with windows vm? Just to verify that you igpu passthrough is working properly. I had hard time making it work in proxmox, and that was with windows vm. Seen lots of discussion about 5700G igpu passhtorugh not working. |
@PRBB28, it worked with macOS for a bit - then I was forced to change MB and CPU (same CPU, different MB), and now it doesn't work again, so 5700G passthrough is definitely possible. However, I'll check same configuration with Win/Linux, it might bring more clues to the scene. @VisualEhrmanntraut, ty, I'll try opening an issue in Lilu bugtracker. Will come back here later with information from them |
Well, as I see it's a problem with Lilu, so I can't really do anything about this. I guess you'll need to find a way to get GOP working with a passed-through GPU. |
macOS Version
Sonoma
What is your CPU's model?
AMD Ryzen 5700G
Please describe the behaviour in detail.
Hello! I'm trying to set up macOS on QEMU/KVM with GPU passthrough. Fixed most of the things, the next one is GPU.
When I'm trying to boot with NootedRed, system just hangs at GPU initialization. Logs stop, and there's a reboot in the next few seconds (even with
keepsyms=1 -v debug=0x100
). Without the kext, system boot fine and recognizes the GPU - but no graphics acceleration available, as expected. With or without the kext, the HDMI output is blank (contains lastudev
messages beforevfio-pci
takeover).My host OS is:
My guest macOS is:
My config.plist: config.txt
My QEMU boot command
IORegExplorer showing the passed GPU
GPU in system information
OS boot hang location
My ACPI definitions (as seen from OpenCore): acpi.zip
Thank you for the great work! I hope this one can be solved too. Really want the acceleration for snappy UI, and host doesn't need the iGPU at all
What should've happened instead?
macOS should boot as expected and provide graphics acceleration
If applicable, attach the .gpuRestart, .panic, etc file related to this issue.
No response
The text was updated successfully, but these errors were encountered: