VirtualBox

Ticket #19152 (closed defect: fixed)

Opened 8 months ago

Last modified 4 months ago

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

Reported by: birdy 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

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

Change History

Changed 8 months ago by birdy

Screencast

comment:1 Changed 8 months ago by birdy

This issue affect VirtualBox 6.0.14 as well.

comment:2 Changed 8 months ago by birdy

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 Changed 8 months ago by birdy

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.

Changed 8 months ago by birdy

5.2 and 6.1 logs

comment:4 Changed 8 months ago by ramshankar

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 8 months ago by ramshankar (previous) (diff)

comment:5 Changed 8 months ago by birdy

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.

Changed 8 months ago by birdy

Video settings for an XP VM

comment:6 Changed 8 months ago by birdy

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 8 months ago by birdy (previous) (diff)

comment:7 Changed 8 months ago by birdy

@ramshankar

Any updates? Have you managed to download the VM?

comment:8 Changed 8 months ago by ramshankar

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 8 months ago by ramshankar (previous) (diff)

comment:9 Changed 8 months ago by birdy

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 Changed 7 months ago by ramshankar

The regression exists somewhere in the range r121012 and r122076.

comment:11 Changed 7 months ago by birdy

This PR is probably related: #18753

comment:12 Changed 7 months ago by ramshankar

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 Changed 7 months ago by birdy

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 Changed 7 months ago by ramshankar

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 follow-up: ↓ 17 Changed 7 months ago by 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!

comment:16 follow-up: ↓ 18 Changed 7 months ago by 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

comment:17 in reply to: ↑ 15 Changed 7 months ago by birdy

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 7 months ago by birdy (previous) (diff)

comment:18 in reply to: ↑ 16 Changed 7 months ago by birdy

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 7 months ago by birdy (previous) (diff)

comment:19 Changed 7 months ago by WayneB64

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

Version 0, edited 7 months ago by WayneB64 (next)

comment:20 follow-up: ↓ 22 Changed 7 months ago by 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.

Last edited 7 months ago by TIMMAH! (previous) (diff)

comment:21 Changed 7 months ago by TIMMAH!

Last edited 7 months ago by TIMMAH! (previous) (diff)

comment:22 in reply to: ↑ 20 Changed 7 months ago by ramshankar

  • Status changed from new to closed
  • Resolution set to fixed

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 7 months ago by ramshankar (previous) (diff)

comment:23 Changed 4 months ago by bjh

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.

www.oracle.com
ContactPrivacy policyTerms of Use