search

quickemu-project / quickemu

Quickly create and run optimised Windows, macOS and Linux virtual machines
MIT License
10.96k stars 479 forks source link

triage: macOS locks up running Quickemu on AMD Ryzen 4000 or 5000 series mobile CPUs? #1273

Open Mustafa-Agha opened 5 months ago

Mustafa-Agha commented 5 months ago

01

It always stuck, and restart, I don't know why?

lj3954 commented 5 months ago

Please try the latest version of quickemu from git. macOS CPU flags have been changed considerably since v4.9.4 was released.

Mustafa-Agha commented 5 months ago

I'm using the latest version

https://github.com/quickemu-project/quickemu/releases/tag/4.9.4

I used this one

Is this the latest version?

It installs mojve os correctly, however ventura and somoma don't work.

lj3954 commented 5 months ago

I'm using the latest version

https://github.com/quickemu-project/quickemu/releases/tag/4.9.4

I used this one

Is this the latest version?

It installs mojve os correctly, however ventura and somoma don't work.

That is the latest tagged release, but it does not contain the latest changes. While v4.9.5 is not released, please clone the repository and try using the quickemu script directly from it.

Mustafa-Agha commented 5 months ago

The same problem happened, I used this repo

git clone --recurse-submodules https://github.com/quickemu-project/quickemu.git

and then used this command

./quickemu --version >> 4.9.5

./quickget macos ventura ./quickemu --vm macos-ventura.conf

first the instance restarted then when I entered (macOS Base System) it became stuck again.

I don't know if this a problem with amd cpu or what?

tomchiverton commented 5 months ago

Mac OS Sonoma boots to a black screen here, post installer, having picked the installer once after reboot. This is using quickget/quickemu from Git this morning.

I think something is badly wrong, but the log file is empty.

Mustafa-Agha commented 5 months ago

Same here. The log file is empty, and the boot screen is stuck. It won't load the installer.

Tested on ventura and sonima both didn't work, testing it now on monetary to see if this is related to ventura and Sonoma only

lj3954 commented 5 months ago

@TuxVinyards More needs to be looked into regarding the CPU flag. I think I found something that may be of high importance. I'm not sure what the case is on Intel platforms, but on my AMD system, invtsc, which is a flag that OSX-KVM included in the penryn argument, is reported as constant_tsc instead. Quickemu bash does not catch it.

For the people here experiencing these issues, I'd recommend trying to launch your VM with my project, quickemu-rs. It makes use of a library which interacts directly with the CPU, so it shouldn't have any problems with inaccurate parsing of supported CPU flags. That would help us understand where the issue lies.

TuxVinyards commented 5 months ago

@lj3954 I did say that the formula was wrong. I rewrote it and showed you the improvements.

But all I got was a flea in my from @flexiondotorg for "self promotion" of qqX.

Meanwhile, you have become 'The anointed one' and have decided to self promote your ideas 😂

If I had stuck with your ideas, we would all still be working with failure. All you have ever done is moan and complain and say nothing should be changed from what we had back in 4.9.2.

It's all getting very tedious.

At least my formula works for me and none of the qqX users are lamenting to me either ....

lj3954 commented 5 months ago

@lj3954 I did say that the formula was wrong. I rewrote it and showed you the improvements.

But all I got was a flea in my from @flexiondotorg for "self promotion" of qqX.

Meanwhile, you have become 'The anointed one' and have decided to self promote your ideas 😂

If I had stuck with your ideas, we would all still be working with failure. All you have ever done is moan and complain and say nothing should be changed from what we had back in 4.9.2.

It's all getting very tedious.

At least my formula works for me and none of the qqX users are lamenting to me either ....

Rather than addressing what I brought up, you choose to attack me for "promoting my ideas" by recommending testing with a project which should theoretically function in exactly the same way, to see where the issue lies. It's quite strange how you always complain about how unwilling I am to work with others, when virtually none of your work is contributed upstream. Contrast that with my continuation to fixing and improving bash quickemu, despite writing a project intended to supersede it.

I made it very clear that my position was that no changes should be made unless it was clearly shown that the old approach had issues, and that said issues could be fixed. I don't believe you, me, or anyone else in those discussions had real, tangible issues with the original argument. You preferred to instead talk about pointless things such as how the penryn architecture is "old" and doesn't "officially" support said amount of cores. Those who did are coming to report that one solution, apparently not the one you prefer the most, is also causing issues. Why don't you propose a fix, if you have this magical solution that everyone needs. Unlike you, I'm not recommending my project as a permanent solution for everyone to switch to and completely disregarding everything else, rather, just a step in troubleshooting an issue here.

TuxVinyards commented 5 months ago

I think I found something that may be of high importance. I'm not sure what the case is on Intel platforms, but on my AMD system, invtsc ....

I have already mentioned similar here 3 weeks ago.

I made it very clear that my position was that no changes should be made ...

Yes, you did. Continually.

.... unless it was clearly shown that the old approach had issues

Yes. I did show you. But you kept ignoring me.

Why don't you propose a fix, if you have this magical solution that everyone needs.

Not saying it's 'magical' but I did propose one and that got ignored too: https://github.com/quickemu-project/quickemu/issues/1114#issuecomment-2129370687

I then proposed a fix on another issue here and got the flea in my ear that I mentioned.

So, I gave up

and put my work here so people can choose for themselves:

You always have to have areas where you agree to disagree and find option solutions for different ideas.

But

I can't have entirely given up, otherwise I wouldn't be taking the time to reply, I suppose?

Even after @zen0bit following his myriad of contributions seems to have walked away completely:

I would like to think that it is just hurried people who are not understanding or who are misunderstanding. People who are possibly pressured making snap decisions and comments that they possibly regret but hope people understand as such. And so forth.

I would like to think something might be done about issue #1113 too. Closed as 'completed' but never fully addressed.

And

This Quickemu branch here has the new qqX cpu formula which should be able to run as plain Quickemu without the need to install qqX , if you want to.

Mustafa-Agha commented 5 months ago

so you still working on the problem guys, or it was solved?

lj3954 commented 5 months ago

@Mustafa-Agha please try quickemu from https://github.com/TuxVinyards/quickemu/tree/freespirit-dev-tweaks and report back whether it fixes the issue.

lj3954 commented 5 months ago

@TuxVinyards the comments you made in https://github.com/TuxVinyards/quickemu/commit/174232ceb244dd883b27b811a4893bd1fe4cb777 aren't clear. Are 8 cores required for the VM to boot, or just for macOS to display a processor name?

TuxVinyards commented 5 months ago

@lj3954

The comments you made in TuxVinyards@174232c aren't clear. Are 8 cores required for the VM to boot, or just for macOS to display a processor name?

Presume this comment in the code:

Tests suggest edit of .conf file to cpu_cores="8" ie 4 core x 2 threads for MacOS to recognise Xeon

My guess is that if MacOS recognises the iMacPro 2017 when it is set at ="8" then things under-the-hood will generally be happier.

https://en.wikipedia.org/wiki/IMac_Pro#Technical_specifications

The OS will boot and run when set at ten or more. Please feel to experiment but as stated in my qqX wiki do backup copy the whole of Mac OS folders before starting. Lots of ancillary files can get changed during processes.

I think the way forward for more powerful setups will be to use Cascade Lake. I want to have a look at that.

A lot of people, me included, are getting tempted by the new Zen 5 processors. When I bought my current main processor, I was lucky to even get that. Chips were really hard to get hold of, certainly here in Europe. Now we are in the era of desktop CPU's with 16 cores, huge government support for new fabs and 2, 3 and 4 nm becoming common place.

Cascade Lake, the Mac Pro 2019, can be set to have up to 28 cores, so I am seeing something like --macpro-2019 as a Quickemu switch that would allow users with newer hardware to enable this instead of a default of iMac Pro 2017. Although, as with Skylake, a lower core number may be needed here too, say 16 ??

https://en.wikipedia.org/wiki/Mac_Pro#Specifications_3

The other thing I want to do is to have a config setting that allows individuals to turn off any Qemu CPU flags when an unexpected compatibility problem happens with the physical hardware. Something in the .conf file like MacCPU_NoFlags=("pqr" "xy-z")

lj3954 commented 5 months ago

My guess is that if MacOS recognizes the iMacPro 2017 when it is set at ="8" then things under-the-hood will generally be happier

Keep in mind that the actual computer has an 8-core processor with 16 threads. Quickemu, when set to cpu_cores=8 on a host supporting SMT, will emulate a 4-core processor with 8 threads. Also, are you sure the VM will boot with 28 cores selected? I tried it, and it hung immediately. #865 is relevant to this.

so I am seeing something like --macpro-2019 as a Quickemu switch

Good idea, quickemu definitely should have a way to configure the hardware passed to the VM. I think it should be set in the config file though, rather than as a flag. It's not an option that people have to modify each time they boot the VM. I've thought about similar for aarch64 VMs with my quickemu-rs project (i.e. emulating SBCs).

allows individuals to turn off Qemu CPU flags when an unexpected compatibility problem happens

I think the majority of quickemu users won't have a clue where to start with an option like this. On top of this, you'll have to check each CPU flag for validity before passing it to QEMU. CPU flags should be done out of the box for the user, I think the configuration emulating different hardware would remove the need for this.

TuxVinyards commented 5 months ago

Keep in mind that the actual computer has an 8-core processor with 16 threads.

:rofl: Very true. So many Xeon variants and two meanings for core just to get everyone confused. Have I accidentally discovered something?

Here it says ' 8 core' https://en.wikipedia.org/wiki/IMac_Pro#Technical_specifications

But here the term does get clarified: https://en.wikipedia.org/wiki/Skylake_(microarchitecture)#Workstation_processors

There are 4 core (8 thread/core) Xeons but iMac Pro uses the W-2140B of course.

So, remembering that we are booting with a virtual CPU, I tested running 8/16 on top of my 6/12 Host, again, so I could get some more screenshots. Maybe when the About dialog reports Xeon at 4/8 in fact Apple are highlighting the CPU as not being an iMac .... The other way round.

Performance wise, there was no difference whether I booted with cpu_cores=8 or =16.

sonoma-16-core

TuxVinyards commented 5 months ago

Also, are you sure the VM will boot with 28 cores selected? I tried it, and it hung immediately.

I gave cpu_cores=28 a try to see what happened for me.

Quickemu or qqX throttled me down somewhere:

  -cpu Skylake-Server-v3,kvm=on,vendor=GenuineIntel,vmware-cpuid-freq=on,pdpe1gb=off,clwb=off
  -smp cores=8,threads=2,sockets=1
  -m 12G

But I noticed Qemu complaints this time. Didn't remember getting them when I specified equals 16:

qemu-system-x86_64: warning: Number of SMP cpus requested (16) exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: warning: Number of hotpluggable cpus requested (16) exceeds the recommended cpus supported by KVM (12)

Then I reset to =16 the Qemu KVM messages were still there. Disappeared when I reset to =8.

Perhaps there's a KVM limiter too. I only have 12 threads available. @lj3954 what happens for you. How many CPU threads can you get access to?

Edit: perhaps this is the real reason why the above =16 test didn't report Xeon? It was actually running at 6/12 ?

I'll have a further look tomorrow.

lj3954 commented 5 months ago

Edit: perhaps this is the real reason why the above =16 test didn't report Xeon? It was actually running at 6/12 ?

The VM won't boot when set to 6c/12t. You're definitely not being limited to that.

Quickemu will round down the thread count to a power of 2, because the VM won't boot otherwise. You can try manually launching the sh file after editing it to another number, it won't work.

TuxVinyards commented 5 months ago

@lj3954 thank you for that.

I have now added cpu_cores=8 =16 =32 to notes as the being only workable values. All these three worked for me, even on six physical cores and with no apparent core loss either. Despite the KVM advisory even 16/32 core machines seemed stable and the requested core numbers were reported as such by lscpu. How many cores were actually being run by KVM is another matter of course.

The other thing that I have done is to add in optional dev code for CascadeLake to https://github.com/TuxVinyards/quickemu/tree/freespirit-dev-tweaks for anyone who wants to try it.

After extracting and diffing the Sky and Cascade code from the Qemu CPU source, I was quite surprised to see how similar the two versions are. Mac Pro 2019 may sound newer but has only two extra flags.

I was pleased to see sysctl -a consistently reporting the correct CPU name, although it's a slight puzzle that even when using Cascade to download and install from scratch, the 'About' dialog still doesn't report anything other than iMacPro 2017.

Until the 'About' box issue gets solved, being able to run 16c/32t on Skylake is probably sufficient though and probably the one to go with as it reports more accurately.

Anybody wanting to test either version of this code can download here and simply extract to a test folder. Follow up by placing a copy of an existing mac-folder and .conf in with all the files. Open a terminal in that folder from your file manager and type ./quickemu --vm macos-whatevername at the prompt. Note the ./ prefix.

flexiondotorg commented 5 months ago

Fixed via https://github.com/quickemu-project/quickemu/pull/1208

lj3954 commented 5 months ago

Fixed via #1208

No, it isn't. Check comment https://github.com/quickemu-project/quickemu/issues/1273#issuecomment-2160616895.

flexiondotorg commented 5 months ago

I have tested the tip of git (effectively 4.9.5 release candidate) on several different models of Ryzen CPU and can not reproduce this issue :disappointed: I will test again later using my AMD Ryzen 7 PRO 6850U laptop.

qemu-system-x86_64: Property 'Skylake-Server-v3-x86_64-cpu.constant-tsc' not found

I'll leave this open to gather more information that can hopefully identify the root cause. I welcome pull requests that demonstrably address whatever the root cause of this issue might be.

popey commented 5 months ago

I may have an option to move forward from a wedged / black screen macOS VM, part way through the install - likely stuck in the EFI with the screen blanked.

Using quickemu 4.9.5 from the PPA on Ubuntu 24.04 on my ThinkPad Z13. My system:

image

I tried installing macOS Ventura. I walked away to do some work, and when I came back, I had a black screen, thus:

image

I tried to anything in the window (click with mouse, press keys) nothing happened. I couldn't determine the state.

However, I was able to use the Qemu monitor to inject keypresses that 'woke' the screen up.

You'll need 'socat' to do this, and know the path to the macos-ventura-monitor.socket (or similarly named file) in the quickemu macos VM folder. Here's what I used:

$ socat - unix-connect:/home/alan/VMs/macos-ventura/macos-ventura-monitor.socket

You'll get this prompt from QEMU:

QEMU 8.2.2 monitor - type 'help' for more information
(qemu)

You can send keypresses, and mouse clicks. So at the (qemu) prompt, type sendkey then the key you want to send. There's a prescribed named list of keys.

So, sendkey esc which 'virtually presses' the escape key.

(qemu) sendkey esc
sendkey esc

etc.

You can also click the mouse with mouse_button n where n is the mouse button number 1, 2, 3 etc.

(qemu) sendkey mouse_button 1
mouse_button 1

This woke the display up. It's possible I may have pressed a number of keys (left, right, ret etc) so worth a play.

image

I was then able to progress the install:

image

Maybe give that a try?

lj3954 commented 5 months ago

can not reproduce this issue

Neither can any of us. macOS issues are extremely hardware dependent, we've been waiting for @Mustafa-Agha to try @TuxVinyards' quickemu branch which has a different way of handling macOS CPU arguments.

The constant_tsc CPU flag can not be passed to the Haswell-v2 and Skylake-Server-v3 CPU models offered by QEMU:

To the best of my knowledge, constant_tsc and invtsc are the same thing. It's just another instance of QEMU using a different name for the CPU flag than lscpu. I think it's also probable that the Haswell and especially Skylake CPUs have this flag enabled by default, so it's nothing to worry about.

xdmx commented 5 months ago

I have the same problem, with a ryzen 4750u (and 32 gb of ram), I've tried both 4.9.5 and @TuxVinyards' quickemu branch, but the VM keeps restarting or gets stuck after I select to start the installation. This happens with monterey, ventura and sonoma. I was able to install both catalina and big-sur without issues. catalina was also working pretty well, but I unfortunately can't use it because I'd need a newer xcode version, while big-sur was very laggish and I could barely use it, even after bumping the VM memory to 16gb.

Let me know if there is any way I can help you debugging this, happy to try other configs/branches

flexiondotorg commented 5 months ago

It seems that everyone having stalls/lockups running newer macOS with Quickemu is using a mobile Ryzen SKU of 4000U or 5000U series.

I have tested on two Ryzen 6000U SKUs and can not reproduce the issue. So, I think we have an avenue of investigation. I don't have a 4000U/5000U system to test with sadly :disappointed:

tomchiverton commented 5 months ago

Maybe just some more detailed logging would help - possible CPU instructions used, ones used after filter etc ?

puresick commented 4 months ago

It seems that everyone having stalls/lockups running newer macOS with Quickemu is using a mobile Ryzen SKU of 4000U or 5000U series.

I have tested on two Ryzen 6000U SKUs and can not reproduce the issue. So, I think we have an avenue of investigation. I don't have a 4000U/5000U system to test with sadly 😞

@flexiondotorg I can confirm that I have similar issues on a AMD Ryzen™ 7 PRO 5850U.