virtualbox.org

I have been running Virtualbox for about 4 years from 3.x to 4.2.x and now 4.3.2, yes, I skipped 4.3.0
I have a combination of Linux hosts running 32bit and 64bit Centos or Mint. I have a number of WinXP Guests (all 32bit), but some with single CPU and others with multiple CPU configurations. I have never had a noticable performance problem until 4.3.2. I cannot claim optimal performance, but it was not a issue.

Investigation pointed to common areas:
- Multiple CPU configurations
- VT-x / AMD-v configurations
- IO APIC - configurations.

Well, testing showed that modifying any combination of my settings on the above made little to no difference on my 4.3.2 performance issues.
What did make the difference was what had to happen to do the testing on the IO APIC. Thanks to thread viewtopic.php?f=1&t=21480.

What I found was the update of the Computer Processing driver provided the general fix.
I repeated the fix on multiple guest configurations with similiar results.
A fully loaded WinXP image, multi-cpu and auto starting background apps - before fix:105 seconds to boot to logon screen - after fix: 35 seconds.
A basic WinXP Image, single-cpu, nothing installed - before fix: 53 seconds to logon screen - after fix: 15 seconds.
In each case, before the fix, even once booted, lag on commands existed (which never existed before) and after fix, the lag was gone.
(Aside: Timing measurements were done without anything else running on the system and 2 complete boot/shutdowns prior to the timing measurement).

The fix:
Boot the Guest OS
Go to Device Manager, and click on "Computers"~>
Select the Properties of "ACPI Uniprocessor PC" or "APCI Multiprocessor PC" ~>
Click on the Driver tab, select Update Driver, ~>
Click on the "Install from list or specific location"~>
Click "don't search I will choose what driver to install" ~>
In the window find and click on "Advanced Power and Configuration Interface (ACPI) PC" then click next ~>
Click "finish" after Windows loads the new drivers. You may need your CD.(I didn't)~>
Now click Close to exit those property pages, Windows will tell you to Reboot. DO NOT REBOOT! SHUTDOWN THE GUEST
Boot the Guest OS
Logon if necessary, the Guest will install more drivers. Let it finish and it will want to reboot again.
Reboot this time

At this point, the performance is fixed. Notice, NO changes to the VirtualBox configuration.

In so many words, what you're saying is that Windows XP guests work better with the "old" HAL and 8259A interrupt controller rather than the APIC. That's not news. What is news is that VBox 4.3 would have changed anything.

Please post the VBox.log for your VM (since you didn't change the VM settings, whether the log is from before or after changing the HAL doesn't matter). The behavior you're seeing probably strongly depends on the specific host hardware. Based on the numbers for posted (thank you very much for doing so!), the slowdown should be obvious... so the fact we didn't notice it implies it's not something that happens to everyone.

I cannot comment on the comment on "Windows XP guests work better with the "old" HAL and 8259A interrupt controller rather than the APIC", as I am not sure of the specifics of what changed when I did what I did. What I can say is that the performance once the change is made does not really change much with IO APIC enabled or disabled. The fix seems to be the driver in the WinXP Guest.

Attached are TWO LOGs. The old one has a delay in boot up, the new one no delay. Only change was the internal setting in Guest.

bknonix wrote:What I can say is that the performance once the change is made does not really change much with IO APIC enabled or disabled.

Yes, that's the whole problem with old Windows XP is too inflexible and does not react to hardware changes, it uses whichever HAL was installed. If you use the non-APIC HAL, then enabling I/O APIC just has no effect. If you use the APIC HAL, disabling I/O APIC will cause XP to fail booting.

Attached are TWO LOGs. The old one has a delay in boot up, the new one no delay. Only change was the internal setting in Guest.

Thanks. The logs aren't conclusive evidence but assuming that they were created under more or less the same conditions, it's clear that in one case the guest booted much slower. The "Guest Additions capability report" entry in the log file is at 2:17 in one case and just 31 seconds in the other.

It's also apparent that you're using AMD-V, which is probably the crucial piece of information in this case. There's an AMD-V specific optimization in VirtualBox called "TPR Patching" that's meant to speed up 32-bit Windows when the I/O APIC is used.. It's not active in your VM because the guest OS type appears to be set to 64-bit (see "fHMForced=true - 64-bit guest" in the log). Is that true? If not, could you please attach your VM's XML settings file ("WinXP - BaseEmpty.vbox" or something like that)?

Thanks for the information, things are starting to make sense.
First, my WinXP Guests are all 32bit and actually, most are clones off the same base.
Here is the config file: Now, I have also confirmed that after the changes I have made, all my images are running the NON-APIC HAL, which makes them work great from a performance perspective. Some of them do have multi-cpu's enabled in VBox, but a double check of their handling, non of them are actually using any more than one CPU. Again, this is all making sense now.

So, I attempted to create a new image, with MULTI-CPU, APIC, etc, etc, etc and the performance is horrible.

Thus, the question then rises. What changed in 4.3.2 to break this badly? My multi-cpu images used to work great and did use all the CPUs before?

bknonix wrote:Thus, the question then rises. What changed in 4.3.2 to break this badly? My multi-cpu images used to work great and did use all the CPUs before?

We know of one semi-unintentional change that will affect AMD-V hosts only. We don't know if there might be more. Please run "VBoxManage modifyvm <vmname> --longmode off" on your VM which uses the APIC HAL.

Right now, your VM logs contain the line "HM: TPR Patching disabled". After the above change, there should be "HM: TPR Patching enabled" instead. Please report whether that really changed and most importantly, if there was a visible performance impact on the guest. Attaching the VBox.log file probably won't hurt in either case.

Having same issue as bknonix but my system was even slower. Initially thought it was the 3D Video Acceleration that I install under WinXP Safe mode but it wasn't. I had to disable hardware acceleration and ofc reduce my core down to 1 to get the container to boot with any reasonable speed. The issue is present in both Virtualbox 4.3 and 4.3.2. I reverted back to 4.2.18. And yes, it only affected WinXP 32bit. My WinXP-64, Win200332/64, Win7-64 and OpenSuse 12.3-64 containers all ran fine with the 4.3x versions of Virtualbox.

System Specs:
Mainboard: Gigabyte-990FXA-UD3 (rev 3.0)
RAM: 32GB
CPU: AMD FX-8350
Video: nVidia GFX 660

FuguRitual wrote:And yes, it only affected WinXP 32bit.

So what does your VBox.log file say? TPR patching enabled or disabled? And if you follow the suggestion in the previous post, what happens?

michaln wrote: It's also apparent that you're using AMD-V, which is probably the crucial piece of information in this case. There's an AMD-V specific optimization in VirtualBox called "TPR Patching" that's meant to speed up 32-bit Windows when the I/O APIC is used.. It's not active in your VM because the guest OS type appears to be set to 64-bit (see "fHMForced=true - 64-bit guest" in the log). Is that true? If not, could you please attach your VM's XML settings file ("WinXP - BaseEmpty.vbox" or something like that)?

i am having the same issue on xp guests and core i7 processors so that isn't specific to amd-v

Sorry for the delay, but I had completed a cleanup of my VMs and did not have a reference VM available to do the test and compare to, so I need to pull something from Backups and redo the tests.

Attached are 2 log files based on the new image I pulled from backups.

Here are the same logs with APIC off...

michaln wrote:So what does your VBox.log file say? TPR patching enabled or disabled? And if you follow the suggestion in the previous post, what happens?

I had removed 4.3.2 just prior to finding this thread so I don't have the logs but I will save the logs from 4.2.18 and re-install 4.3.2 temporarily so that I can upload 4 logs like bknonix did. I'll have them up by Monday.

FuguRitual wrote:

michaln wrote:So what does your VBox.log file say? TPR patching enabled or disabled? And if you follow the suggestion in the previous post, what happens?

I had removed 4.3.2 just prior to finding this thread so I don't have the logs but I will save the logs from 4.2.18 and re-install 4.3.2 temporarily so that I can upload 4 logs like bknonix did. I'll have them up by Monday.

--------------------------------------------------------------

Attached are two (2) logs and one (1) composite screenshot of Vbox settings.

In the unlikely event that someone asks regarding my BIOS:
No CPU or GPU overclocking
AMD C1E set to "Auto"
AMD C6 set to "Enable"
Virtualization set to "Enable"
IOMMu support set to "Enable"

Also, the Vbox settings were identical for both versions. I cannot disable IO APIC, and do not want to disable hardware virtualization or change the HAL. Unlike bknonix, I prefer running 4.2.18 until there is a fix or move the WinXP 32bit containers to another virtualization app since they are the only OS affected.

Hope our combined logs can lead to a solution.

Just saying hello to the forum adding that changing the APIC driver to the one proposed by the original poster also worked for my WinXP VM. Under OS X 10.8.5 host OS. I had created a new VM with 4 CPUs only to read about APIC and winXP later on.

OK, I tried that as well. Amazingly faster performance! But... how many processors are you left with after you apply the "patch"? From my point of view, although the VM is given 4 CPUs in VBox, in TaskManager and everywhere else I get 1 (one). Anyone else?