Huge IO-APIC/guest SMP overhead with 32 bits guests

noticed the following, if I disable the IOAPIC and set VCPU to 1, install goes fine and fast ...

Known problem and mentioned in the manual. 32 bits guests are extremely slow with the IO-APIC enabled on AMD cpus. Will be fixed in a future release.

I can confirm this behavior on 3.0.2 on AMD Phenom, Mandriva 2009.1. I can also confirm that changing the HAL on the guest VM to Advanced Configuration and Power Interface (ACPI) PC, changing the VM properties to disable IO-APIC, single vCPU. The guest then runs quickly and without problems - but of course, single vCPU. Is there any roadmap for a fix?

The exact same VM runs fine with multiple vCPU and IOAPIC on Intel VT-x, what's the problem with AMD-V ?

It's being worked on. Intel provides an optimization feature for APIC TPR access. AMD does not, so I have fix it myself.

Similar statements also apply to VMs running Standard PC HAL compared with MPS Multiprocessor HAL. Switching to Standard speeds it up very much with the IOAPIC turned off in the VM settings.

Do we have a possible timeline for a fix, either a whole new version of VB3 incorporating AMD-friendly technology, or a patch to 3.0.2 ?

Fixed in 3.0.6, but only after you've installed the 3.0.6 guest additions.

Thanks for the good work on this bug. I will be testing it as soon as I can get my hands on 3.0.6.

Can I please ask you to regression-test this fix against Windows XP 64-bit Edition on AMD-V [3.0.4 crashes when Nested Paging is on, machine occasionally aborts without warning or logging an error when Nested Paging is off]. Host is 32-bit Mandriva 2009 and 2008.

Windows 2000 SMP under Ubuntu 9.0.4 64-bit VT-x

It's not AMD-V only; my VT-x does it too, even with 3.0.6 Guest Additions installed. (See attachment.)

Windows 2000 SMP with Ubuntu 9.0.4 64-bit VT-x.

mike: please don't mention unrelated problems in this defect. If you still see this xp64 abort with 3.0.6, then open another defect with a proper description and VBox.log.

greerga: your Intel CPU doesn't support the APIC access optimization. I intend to enable the same fix once we get more feedback about AMD-V.

Replying to sandervl73:Point taken about 64-bit, I will keep testing that and raise a new issue for it.

However... my testing of 3.0.6 with XP 32-bit on AMD-V has shown that it's better - and it's worse. It's better - when you choose a guest ACPI Multprocessor HAL or ACPI Uniprocessor HAL, it runs without taking half an hour to boot up and flatlining one or two CPU cores at 100%. Most of the time. However today it went back to behaving like the un-patched 3.0.4 problem. I fixed this by running sudo /etc/init.d/vboxdrv restart . Clearly something in the VirtualBox drivers can revert to the old behavior given some [unknown] circumstances.

If you build your guest with the Advanced Power Configuration Interface (ACPI) HAL [i.e. no IOAPIC, as was required on 3.0.4 to work], it runs, but not as quickly as it used to on 3.0.4. So the fix has crippled non-IOAPIC but has not completely raised the performance level of IOAPIC-based configurations.

The typical performance issue is that the SysInternals? Process Explorer is showing that System and Services.exe are together taking 6% or more all the time, even with dual 2.3GHz vCPUs. This is way short of physical machine performance. So the system has a performance draining wait loop somewhere inside it, meaning that activities like Windows Installer take far longer to complete than expected unless you intervene with Process Explorer and raise the process priority to "High".

It's a shame - this so nearly worked. The fact is that 3.0.4 with IOAPIC disabled and one vCPU massively outperforms 3.0.6 with dual vCPUs, which seems counter-intuitive.

Also I have had numerous aborts when Guest Additions 3D Acceleration is enabled.

Just getting myself on the Cc: list (couldn't find another way). Just ignore.

I have exactly the described issue with VirtualBox 3.0.10, 32bit Kubuntu 9.04 host and 32bit Windows XP guest. My processor is a Core 2 Duo E6420 which does support 64bit. However, reading the "current status", I'm not sure what exactly is in SVN only - the fix for Intel processor supporting 64bit or the fix for those which don't.

VBox 3.1.0 will contain a fix for Windows guests which works if the guest additions are installed and if the host CPU supports VT-x and 64-bit. I known, it sounds a bit strange that 64-bit support is required to workaround some 32-bit issue :)

Well, the current status in the ticket description should be clear.

Ok, thanks for clarification - I hope for version 3.1 then :)

Is there any plan/solution you are working on for 32 Bit Hosts? I use a (beloved) Pentium M Notebook with 2 GB Ram which can handled non-APIC VM's with acceptable speed (for office etc) but nearly grinds to hold and suffers huge delays when using an almost exactly configured VM, which was installed (and has to run) with APIC enabled. This causes a rather huge administrative burden for me, because I have to keep two Versions of practically the same VM updated and running. One for my 64 Bit Host(s) and one for my 32 Bit Host.

The 3.0.12 changelog says: VMM: reduced IO-APIC overhead for 32 bits Windows NT/2000/XP/2003 guests; requires 64 bits support (VT-x only; bug #4392) However, I still experience this issue after upgrading to the latest version.

ralf: Please attach a VBox.log file of such a session.

ralf: you need to install the 3.0.12 additions and the OS type in the VM settings needs to be correct. The workaround is only enabled for 32 bits NT/2K/XP/2K3 OSes.

Yes, that was the reason I was asking for the VBox.log file :)

The issue occurs long before I can even install the guest additions, during OS installation. I also have an old VM installed when there was no SMP, where I installed the 3.0.12 additions and after doing so copied the hal.dll and ntoskrnl.exe from a multiprocessor system. I will get you a logfile of that one ASAP. Do I have to re-install the additions after changing the HAL?

The performance will not improve until you installed the guest additions and until they are active. That is, the fix/workaround will not work during boot.

I think it is not necessary to re-install the guest additions after you changed the HAL but it cannot hurt. Make sure to use 3.0.12 additions in any case.

Ok, I installed the new HAL and re-installed the latest guest additions. Then I started a new VirtualBox session (so the log file I'll attach soon starts here), started Windows, and indeed the "full load while doing nothing" vanished some time after the additions were loaded, so something improved. However, then I started Warcraft III (to test performance), and it is definitely slower than without IO-APIC (the sound stutters, and the animations are not fluent). I also have the impression that the task-manager process list still flickers a tiny bit, but it's nothing compared to how it behaves without the work-around. At least it's now able to play the Windows shut-down sound without stuttering (the start-up sound is of course still broken).

Any chance of a work-around which is independent of the guest doing some cooperation? In the current state, IO-APIC and SMP will stay disabled here. However, I obviously don't understand anything of the internals of this issue. Since I don't use the VM that often it's not a big deal. It'd just be nice to be able to use both cores. Anyway, keep up the good work, and thanks a lot for making such a great open-source VM :)