Windows XP slow on Apple M1

Bug #1913505 reported by Mishari Muqbil
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Undecided
Unassigned

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.

Revision history for this message
Peter Maydell (pmaydell) wrote :

Is the install that slow on some other hardware (useful comparisons: x86 Mac; x86 Linux; AArch64 Linux) ?

Revision history for this message
Mark Cave-Ayland (mark-cave-ayland) wrote : Re: [Bug 1913505] Re: Windows XP slow on Apple M1

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.

Revision history for this message
Thomas Huth (th-huth) wrote :

Did you compile QEMU on your own? If so, which parameters did you use for the "configure" script?

Revision history for this message
BALATON Zoltan (balaton-4) wrote :

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

Revision history for this message
Mishari Muqbil (mishari) wrote :

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"

Revision history for this message
Peter Maydell (pmaydell) wrote :

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.)

Revision history for this message
John Arbuckle (programmingkidx) wrote :

> 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.

Revision history for this message
Mishari Muqbil (mishari) wrote :

Hi John,

Thank you, this is indeed strange. Do you use homebrew? Could you try the homebrew version and see how that goes?

Revision history for this message
John Arbuckle (programmingkidx) wrote :

I installed QEMU thru home-brew. When I tried to run it I saw this error message: "Could not allocate dynamic translator buffer".

Revision history for this message
Roman Bolshakov (roolebo) wrote :

@John please build from master and apply the patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03527.html

tags: added: macos tcg
Revision history for this message
John Arbuckle (programmingkidx) wrote :

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.

Revision history for this message
John Arbuckle (programmingkidx) wrote :

Just to note when I tried reinstalling Windows XP, the installation appeared to be stuck at this screen. I restarted QEMU to continue.

Revision history for this message
Thomas Huth (th-huth) wrote :

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.

Changed in qemu:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers