diff options
Diffstat (limited to 'results/classifier/105/other/1913505')
| -rw-r--r-- | results/classifier/105/other/1913505 | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/results/classifier/105/other/1913505 b/results/classifier/105/other/1913505 new file mode 100644 index 00000000..31b60a82 --- /dev/null +++ b/results/classifier/105/other/1913505 @@ -0,0 +1,192 @@ +assembly: 0.958 +other: 0.956 +semantic: 0.953 +socket: 0.949 +instruction: 0.947 +boot: 0.943 +vnc: 0.942 +graphic: 0.933 +device: 0.933 +KVM: 0.918 +network: 0.916 +mistranslation: 0.807 + +Windows XP slow on Apple M1 + +Qemu installed by using brew install qemu -s on M1 + +QEMU emulator version 5.2.0 +XP image from: https://archive.org/details/WinXPProSP3x86 + +Commands run: +$ qemu-img create -f qcow2 xpsp3.img 10G +$ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d + +It's taken 3 days now with qemu running at around 94% CPU and installation hasn't finished. The mouse pointer moves and occasionally changes between the pointer and hourglass so it doesn't seem to have frozen. + +Is the install that slow on some other hardware (useful comparisons: x86 Mac; x86 Linux; AArch64 Linux) ? + + +On 28/01/2021 10:33, Peter Maydell wrote: + +> Is the install that slow on some other hardware (useful comparisons: x86 +> Mac; x86 Linux; AArch64 Linux) ? + +Could it be related to excess TLB flushing? Possible related bug report here: +https://bugs.launchpad.net/qemu/+bug/1883593. + + +ATB, + +Mark. + + +Did you compile QEMU on your own? If so, which parameters did you use for the "configure" script? + +The bug report says: +"Qemu installed by using brew install qemu -s on M1" +so I think it's whatver options homebrew used: +https://formulae.brew.sh/formula/qemu + + + +I just realised that I was using an x86 build of qemu on my M1. When I run the arm64 version I get "Could not allocate dynamic translator buffer" + + +Try a newer version from git -- the patches to support emulation on the M1 only went into git very recently. (There are still some issues on this hardware with further patches on list and/or testsuite failures being investigated.) + + + + +> On Jan 29, 2021, at 1:20 AM, <email address hidden> wrote: +> +> Message: 14 +> Date: Fri, 29 Jan 2021 06:06:41 -0000 +> From: Thomas Huth <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1913505] Re: Windows XP slow on Apple M1 +> Message-ID: +> <email address hidden> +> +> Content-Type: text/plain; charset="utf-8" +> +> Did you compile QEMU on your own? If so, which parameters did you use +> for the "configure" script? +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1913505 +> +> Title: +> Windows XP slow on Apple M1 +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu installed by using brew install qemu -s on M1 +> +> QEMU emulator version 5.2.0 +> XP image from: https://archive.org/details/WinXPProSP3x86 +> +> Commands run: +> $ qemu-img create -f qcow2 xpsp3.img 10G +> $ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d +> +> It's taken 3 days now with qemu running at around 94% CPU and +> installation hasn't finished. The mouse pointer moves and occasionally +> changes between the pointer and hourglass so it doesn't seem to have +> frozen. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1913505/+subscriptions + + +Hi, I followed your directions on reproducing this issue. My times were very different from yours. + +I used my own patch to make qemu-system-i386 on my M1 Mac running Mac OS 11.1. It is on the list if you want to try it. + +For Windows XP, I used my own copy. It was build 2600 and Service Pack 3. + +Installing Windows XP took about 23 minutes. After the installation was completed Windows tried to start up but probably crashed so I had to reboot the VM. After that it started up without problems. + +Here are some benchmarks I did: + +For my ARM-based QEMU I saw these start up times to the login screen: 1:20, 1:19, 1:16, 1:18 + +For a QEMU binary I made a few years ago that is x86_64-based, I saw these times: 1:09, 1:09 + +The ARM-based QEMU is at version 5.2.50 (git commit 9cd69f1a270235b652766f00b94114f48a2d603f). + +The x86_64-based QEMU is at version 2.10.1. + +I would have bet that the ARM-based QEMU would run circles around the x86_64 version, but the opposite happened. + +These are my theories about what could be wrong: +- A patch somewhere made QEMU slow + -- feature bloat + -- bugs + -- emulated hardware issues +- The ARM TCG isn't as good as the x86_64 version +- Non-optimal command-line options + +Please let me know if you have any ideas or suggestions. + +Thank you. + + + + + + + +Hi John, + +Thank you, this is indeed strange. Do you use homebrew? Could you try the homebrew version and see how that goes? + +I installed QEMU thru home-brew. When I tried to run it I saw this error message: "Could not allocate dynamic translator buffer". + +@John please build from master and apply the patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03527.html + +Tried the patch. +Start up time does not appear to be improved. +I used both qemu-system-i386 and qemu-system-x86_64 with the same results. +To compare notes I tried Windows 7. It starts up much faster than Windows XP. + + +Just to note when I tried reinstalling Windows XP, the installation appeared to be stuck at this screen. I restarted QEMU to continue. + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |