memory corruption in linux guest => Fixed in SVN

[ralf w]

When running 64bit linux guests with more than 2g of ram on a windows vista or windows 7 host the memory of the guest is corrupted sometimes.

I can check the corruption with the "memtester" tool from Charles Cazabon ( the two guest systems i tested, Gentoo and Ubuntu 10.10, both have packages for this ) and trigger it by switching terminals in gentoo from the framebuffer console ( alt-f2, alt-f1, memory corrupted ) or just let the memtester program run in ubuntu and wait a for some time. Note: memtester has to test almost all available memory.

The corruption always happens at an offset of 0x458 from a page start with a 64bit value of 0x100500000 being somewhow written to the memory address.

This happens with and without guest additions and on the amd-v and intel vt-x platforms i have access to.

I'll attach the Vbox.log of the gentoo guest.

[ralf w]

Gentoo Guest logfile

[Frank Mehnert]

I assume the actual page address changes. Is there some pattern?

[Frank Mehnert]

Oh, and how did you start memtester (which parameters)?

[Frank Mehnert]

Ok, I was able to reproduce this problem. Please check if disabling large pages (VBoxManage modifyvm VM_NAME --largepages off) solves your problem.

[Frank Mehnert]

Oh, I just saw that nested paging is disabled for this VM, so large pages are disabled as well. How does it work if you enable nested paging (bug disable large pages)?

[ralf w]

the problem still exists with

00:00:00.580 [/HWVirtExt/] (level 1)
00:00:00.580   64bitEnabled       <integer> = 0x0000000000000001 (1)
00:00:00.580   EnableLargePages   <integer> = 0x0000000000000000 (0)
00:00:00.580   EnableNestedPaging <integer> = 0x0000000000000001 (1)
00:00:00.580   EnableVPID         <integer> = 0x0000000000000001 (1)
00:00:00.580   Enabled            <integer> = 0x0000000000000001 (1)
00:00:00.580   Exclusive          <integer> = 0x0000000000000000 (0)

[ralf w]

oops.. i meant

64bitEnabled       1
EnableLargePages   0
EnableNestedPaging 1
EnableVPID         1
Enabled            1
Exclusive          0

[Frank Mehnert]

I've tested a newer build and it seems that the issue does not show up anymore. Could you check if ​this build makes any difference for you?

[ralf w]

the 4.0.5 build makes no difference.

im testing with a vm that has 2200mb ram set and call memtester with 2050 as parameter. even then sometimes the faulty address is not included in the tested range so one has to start memtester multiple times ( or reboot the guest ) to shuffle memory around to make sure almost all memory is tested.

the guests physical memory address where the the corruption occurs is constant once linux is booted up so maybe this helps. for the whole 2200 mb ram i dedicated to the vm its then only this one 64bit guest physical memory location that gets somehow overwritten.

[Frank Mehnert]

Thanks for testing. Currently searching for a way to trigger this problem more reliably because so far I saw it only once in several runs.

[ralf w]

have you tried switching consoles while memtester is running ?

[Frank Mehnert]

Yes, does not make any difference here.

[ralf w]

i just tested on a machine with 8gb ram and the problem does not seem to occur ( maybe it does but i cant test it ) when the vm has more than 3,5GB or so dedicated ram but everything between 2100mb and 3500mb shows memory corruption for me on different machines.

[Frank Mehnert]

I think we found and fixed this issue. Please download and install ​this build.

[ralf w]

yes the new build fixes the issue for me. thank you.

[Frank Mehnert]

The fix is contained in VBox 4.0.8.