VirtualBox

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#19152 closed defect (fixed)

Extremely low 2D graphics performance after updating to VBox 6.1 for a Windows XP guest

Reported by: Artem S. Tashkinov Owned by:
Component: VMM Version: VirtualBox 6.0.14
Keywords: Cc:
Guest type: Windows Host type: Linux

Description

I've tried both VBoxVGA and VBoxSVGA and both work horribly slowly.

My host is: Fedora 31, NVIDIA blob, kernel 5.4.2 vanilla

My guest is: Windows XP SP3 32bit

Of course, I've installed guest additions.

Version 6.0 probably worked fine - I can't say for sure. In VirtualBox 5.2 XP flies in comparison.

Attachments (3)

XP-2019-12-13T01-43-32-451654000Z.mkv (494.4 KB ) - added by Artem S. Tashkinov 4 years ago.
Screencast
logs.tar.xz (32.6 KB ) - added by Artem S. Tashkinov 4 years ago.
5.2 and 6.1 logs
Screenshot_2019-12-13_13-32-21.png (56.6 KB ) - added by Artem S. Tashkinov 4 years ago.
Video settings for an XP VM

Download all attachments as: .zip

Change History (26)

by Artem S. Tashkinov, 4 years ago

Screencast

comment:1 by Artem S. Tashkinov, 4 years ago

This issue affect VirtualBox 6.0.14 as well.

comment:2 by Artem S. Tashkinov, 4 years ago

Under VirtualBox 5.2.34 everything works perfectly. I've just verified it again.

That's a major regression and I think it's quite recent because I remember I tried some of earlier 6.0 builds a few months ago, probably 6.0.0 and it worked OK.

comment:3 by Artem S. Tashkinov, 4 years ago

There are no steps to reproduce: just install Windows XP SP3 32bit and you'll see the problem immediately.

I don't use any fancy VirtualBox options and my XP installation is pretty much default.

by Artem S. Tashkinov, 4 years ago

Attachment: logs.tar.xz added

5.2 and 6.1 logs

comment:4 by Ramshankar Venkataraman, 4 years ago

I tried creating a fresh XP SP3 VM, installing the latest VirtualBox 6.1.0 guest additions and enabling 2D acceleration (with VBoxVGA) and I could not notice any slow down in performance.

Of course, my host system was slightly different (an AMD Ryzen 5 Pro 1500 Quad Core, Ubuntu 16.04).

Regardless, there's something about your setup that I'm not able to reproduce the problem.

From the ticket title, you mentioned "2D graphics performance". Is the slow down only happening if you enable "2D acceleration" in the VM's Graphics settings?

  1. Could you disable 2D acceleration and check if performance changes.
  1. If (1) doesn't make a difference, could you uninstall guest-additions and check if performance changes.
Last edited 4 years ago by Ramshankar Venkataraman (previous) (diff)

comment:5 by Artem S. Tashkinov, 4 years ago

There's no such thing as "2D acceleration" in VirtualBox.

There's "2D video acceleration" which has nothing to do with this issue and "3D acceleration" which I apparently don't use at all since I'm talking about basic GUI rendering in Windows XP which is slow as molasses in VirtualBox 6.0.14 and 6.1.

Here are my video settings but I will try to disable 2D video acceleration to see if it might cause any issues.

I will try to toggle this setting but I'm quite positive it will have no effect at all.

by Artem S. Tashkinov, 4 years ago

Video settings for an XP VM

comment:6 by Artem S. Tashkinov, 4 years ago

I've successfully reproduced this issue under Windows 10 host as well.

I've tested:

  • 2D video acceleration ON and OFF
  • VirtualBox addons installed and not installed

All four ways 2D is dog slow. Basic animations are stuttering, on Windows load you can see colors animation stuttering, windows rendering is stuttering.

Here's my guest OS: https://thinfi.com/h9ua (URL password: PRXXXXX where XXXXX are this ticket number).

Last edited 4 years ago by Artem S. Tashkinov (previous) (diff)

comment:7 by Artem S. Tashkinov, 4 years ago

@ramshankar

Any updates? Have you managed to download the VM?

comment:8 by Ramshankar Venkataraman, 4 years ago

Yes, I downloaded the VM and can confirm this is indeed a performance regression that started sometime in the 6.0.x branch.

Investigating the issue with the following info. so far:

  1. The regression only affects AMD hosts. Intel hosts are not affected.
  2. It's not caused by TPR-patching which is specific to XP guests on AMD CPUs.
  3. It's easy to reproduce the problem using "dir /s C:" in guest.

I'm not yet certain where the time is being spent. The usual VM statistics doesn't yet seem to show up anything immediately obvious. It could perhaps be related to PGM or HM's flushing of TLBs or something else... This will require more investigation to track down. In addition, I intend to do a binary search of affected changesets to see if we can find it that way but since the regression occurred quite a while ago, it may take some time.

Thanks for testing. I'll update this ticket when I get more info.

Last edited 4 years ago by Ramshankar Venkataraman (previous) (diff)

comment:9 by Artem S. Tashkinov, 4 years ago

Thank you!

Never expected such a comprehensive reply.

And indeed you're quite right - I now remember that I didn't have this issue on an Intel host with VBox 6.0 while on an AMD host it's reproducible right away.

comment:10 by Ramshankar Venkataraman, 4 years ago

The regression exists somewhere in the range r121012 and r122076.

comment:11 by Artem S. Tashkinov, 4 years ago

This PR is probably related: #18753

comment:12 by Ramshankar Venkataraman, 4 years ago

The regression starts with changeset r121857.

As part of a larger change, initializing the guest PAT (Page Attribute Table) MSR while executing guests using hardware-assisted SVM changed from 0x0006060606060606 (all WB - WriteBack) to 0x0007040600070406 (UC-/WT/WB - the default value on CPU init).

The XP guest is enabling write-combining, setting PAT to 0x7010600070106 but these changes are not honored and VirtualBox continues running the guest with the default value set earlier.

I'll try to fix this soon, backport the changes and update this ticket.

comment:13 by Artem S. Tashkinov, 4 years ago

Don't want to interrupt or bother you for no reason but this change doesn't seem like it's related to AMD specifically. Is there any reason only AMD CPUs are affected?

comment:14 by Ramshankar Venkataraman, 4 years ago

While the PAT MSR is not specific to AMD, the code in question is AMD specific. The bug exists in HMSVMR0.cpp to be precise.

comment:15 by Ramshankar Venkataraman, 4 years ago

This bug has been fixed and backported to 6.0. It will be available in the next maintenance version release of VirtualBox 6.0 and 6.1.

Thanks a lot for reporting and for providing a test VM!

comment:16 by WayneB64, 4 years ago

I am having similar issues with 6.0 on an AMD CPU. I built a brand new state of the are PC and had to upgrade Virtual Box to run on Win 10. My VM compute performance is great but simple things like scrolling a large window of text is REALLY clunky. I am guessing this problem exists in 6.1 as well so no point upgrading to that but when will 6.0 get an update?

Thanks, Wayne

in reply to:  15 comment:17 by Artem S. Tashkinov, 4 years ago

Replying to ramshankar:

This bug has been fixed and backported to 6.0. It will be available in the next maintenance version release of VirtualBox 6.0 and 6.1.

Thanks a lot for reporting and for providing a test VM!

Thank you for a quick acknowledgement and a quick fix!

I've seen too many VB tickets which have been lingering for years and this one is very unusual. I'm positively astonished.

Last edited 4 years ago by Artem S. Tashkinov (previous) (diff)

in reply to:  16 comment:18 by Artem S. Tashkinov, 4 years ago

Replying to WayneB64:

I am having similar issues with 6.0 on an AMD CPU. I built a brand new state of the are PC and had to upgrade Virtual Box to run on Win 10. My VM compute performance is great but simple things like scrolling a large window of text is REALLY clunky. I am guessing this problem exists in 6.1 as well so no point upgrading to that but when will 6.0 get an update?

Thanks, Wayne

All 6.x releases are affected and this bug will be fixed in upcoming 6.x and 6.1 releases. As to when the new versions will be released - I've no idea. I guess in less than two weeks.

Last edited 4 years ago by Artem S. Tashkinov (previous) (diff)

comment:19 by WayneB64, 4 years ago

The update came out today and I now have my scrolling back!

Last edited 4 years ago by WayneB64 (previous) (diff)

comment:20 by TIMMAH!, 4 years ago

This is NOT fixed in 6.0.14 or 6.1.2. (the link for VirtualBox 6.0.16 is broken, so I couldn't try that release).

Basically, VBoxSVGA and VMSVGA are VERY slow when running Windows 10 on a Mac version of VirtualBox (6.0.14 or 6.1.2). It's like 3D acceleration doesn't work. Also, some applications won't work at all, like Chrome (it shows nothing more than a black window).

However, 3D acceleration does work with VBoxVGA (running 6.0.14). Starting with 6.1.0, acceleration for VBoxVGA was removed, so for all intents and purposes, 6.1.x is no longer functional to use on a Mac running a virtual Windows 10 machine.

And yes, the correct version of the extension pack was installed in all cases.

Last edited 4 years ago by TIMMAH! (previous) (diff)

comment:21 by TIMMAH!, 4 years ago

Last edited 4 years ago by TIMMAH! (previous) (diff)

in reply to:  20 comment:22 by Ramshankar Venkataraman, 4 years ago

Resolution: fixed
Status: newclosed

Replying to TIMMAH!:

This is NOT fixed in 6.0.14 or 6.1.2. (the link for VirtualBox 6.0.16 is broken, so I couldn't try that release).

Basically, VBoxSVGA and VMSVGA are VERY slow when running Windows 10 on a Mac version of VirtualBox (6.0.14 or 6.1.2). It's like 3D acceleration doesn't work. Also, some applications won't work at all, like Chrome (it shows nothing more than a black window).

However, 3D acceleration does work with VBoxVGA (running 6.0.14). Starting with 6.1.0, acceleration for VBoxVGA was removed, so for all intents and purposes, 6.1.x is no longer functional to use on a Mac running a virtual Windows 10 machine.

And yes, the correct version of the extension pack was installed in all cases.


This ticket has nothing to do with 3D acceleration.

Please open a new bug (or search for existing bug) regarding your 3D related issues.

This ticket is a VMM bug specific to AMD CPUs as I've described earlier.

Closing this bug as fixed in 6.0.16 (and 6.1.2).

Last edited 4 years ago by Ramshankar Venkataraman (previous) (diff)

comment:23 by Brian Havard, 4 years ago

Just for the record, I had exactly the same problem with a Win7-64 VM so it wasn't just XP. I just tried 6.1.6 and it's much better, back to the speed I had with v5.2.x.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use