我有一个 Debian wheezy (7.4) amd64 虚拟机,在配备 AMD A10-5700 处理器的 Win7 x64 主机上的 VirtualBox 4.3.10 下运行。虚拟机配置了16GB内存(主机有32GB物理RAM,所有这些似乎都能正确识别)。没有其他虚拟机正在运行。尽管如此,Debian VM 看到的 RAM 远少于分配的 RAM。
$ uname -a
Linux debian3 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
$ free
total used free shared buffers cached
Mem: 3610656 958788 2651868 0 181072 379744
-/+ buffers/cache: 397972 3212684
Swap: 3668988 0 3668988
$ dmesg | grep BIOS-e820
[ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000de9df000 (usable)
[ 0.000000] BIOS-e820: 00000000de9df000 - 00000000de9ec000 (reserved)
[ 0.000000] BIOS-e820: 00000000de9ec000 - 00000000dfb6c000 (usable)
[ 0.000000] BIOS-e820: 00000000dfb6c000 - 00000000dfbc4000 (reserved)
[ 0.000000] BIOS-e820: 00000000dfbc4000 - 00000000dfbcc000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000dfbcc000 - 00000000dfbd0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000dfbd0000 - 00000000dffd0000 (usable)
[ 0.000000] BIOS-e820: 00000000dffd0000 - 00000000dfff0000 (reserved)
我确实已将 VirtualBox 设置为在该虚拟机上使用 EFI,因此以下是一些可能相关的消息:
$ dmesg | grep EFI
[ 0.000000] EFI v2.31 by EDK II
[ 0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[ 0.000000] EFI: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x00000000000a0000) (0MB)
[ 0.000000] EFI: mem01: type=2, attr=0xf, range=[0x0000000000100000-0x00000000003b1000) (2MB)
[ 0.000000] EFI: mem02: type=7, attr=0xf, range=[0x00000000003b1000-0x0000000002000000) (28MB)
[ 0.000000] EFI: mem03: type=4, attr=0xf, range=[0x0000000002000000-0x0000000002600000) (6MB)
[ 0.000000] EFI: mem04: type=7, attr=0xf, range=[0x0000000002600000-0x0000000036bf8000) (837MB)
[ 0.000000] EFI: mem05: type=2, attr=0xf, range=[0x0000000036bf8000-0x00000000375f4000) (9MB)
[ 0.000000] EFI: mem06: type=7, attr=0xf, range=[0x00000000375f4000-0x00000000a49a4000) (1747MB)
[ 0.000000] EFI: mem07: type=2, attr=0xf, range=[0x00000000a49a4000-0x00000000dc000000) (886MB)
[ 0.000000] EFI: mem08: type=4, attr=0xf, range=[0x00000000dc000000-0x00000000dc020000) (0MB)
[ 0.000000] EFI: mem09: type=7, attr=0xf, range=[0x00000000dc020000-0x00000000dddc3000) (29MB)
[ 0.000000] EFI: mem10: type=4, attr=0xf, range=[0x00000000dddc3000-0x00000000de1a6000) (3MB)
[ 0.000000] EFI: mem11: type=7, attr=0xf, range=[0x00000000de1a6000-0x00000000de440000) (2MB)
[ 0.000000] EFI: mem12: type=1, attr=0xf, range=[0x00000000de440000-0x00000000de45d000) (0MB)
[ 0.000000] EFI: mem13: type=4, attr=0xf, range=[0x00000000de45d000-0x00000000de9df000) (5MB)
[ 0.000000] EFI: mem14: type=5, attr=0x800000000000000f, range=[0x00000000de9df000-0x00000000de9ec000) (0MB)
[ 0.000000] EFI: mem15: type=4, attr=0xf, range=[0x00000000de9ec000-0x00000000deaec000) (1MB)
[ 0.000000] EFI: mem16: type=7, attr=0xf, range=[0x00000000deaec000-0x00000000deb1f000) (0MB)
[ 0.000000] EFI: mem17: type=2, attr=0xf, range=[0x00000000deb1f000-0x00000000deb25000) (0MB)
[ 0.000000] EFI: mem18: type=4, attr=0xf, range=[0x00000000deb25000-0x00000000df9ec000) (14MB)
[ 0.000000] EFI: mem19: type=7, attr=0xf, range=[0x00000000df9ec000-0x00000000df9ef000) (0MB)
[ 0.000000] EFI: mem20: type=3, attr=0xf, range=[0x00000000df9ef000-0x00000000dfb6c000) (1MB)
[ 0.000000] EFI: mem21: type=5, attr=0x800000000000000f, range=[0x00000000dfb6c000-0x00000000dfb9c000) (0MB)
[ 0.000000] EFI: mem22: type=6, attr=0x800000000000000f, range=[0x00000000dfb9c000-0x00000000dfbc0000) (0MB)
[ 0.000000] EFI: mem23: type=0, attr=0xf, range=[0x00000000dfbc0000-0x00000000dfbc4000) (0MB)
[ 0.000000] EFI: mem24: type=9, attr=0xf, range=[0x00000000dfbc4000-0x00000000dfbcc000) (0MB)
[ 0.000000] EFI: mem25: type=10, attr=0xf, range=[0x00000000dfbcc000-0x00000000dfbd0000) (0MB)
[ 0.000000] EFI: mem26: type=4, attr=0xf, range=[0x00000000dfbd0000-0x00000000dffd0000) (4MB)
[ 0.000000] EFI: mem27: type=6, attr=0x800000000000000f, range=[0x00000000dffd0000-0x00000000dfff0000) (0MB)
[ 1.204229] fb0: EFI VGA frame buffer device
[ 6.734371] EFI Variables Facility v0.08 2004-May-17
还有另一条消息(与 iommu 相关)我很确定不应该出现在这里:
$ dmesg | grep Calgary
[ 0.000000] Calgary: detecting Calgary via BIOS EBDA area
[ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
引导加载程序是grub-efi-amd64
.以上所有输出均来自使用以下配置启动/boot/grub/grub.cfg
:
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd0,gpt2)'
search --no-floppy --fs-uuid --set=root 7d58d543-5c40-4e8d-bbfa-f3773dc7ca15
echo 'Loading Linux 3.2.0-4-amd64 ...'
linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=7d58d543-5c40-4e8d-bbfa-f3773dc7ca15 ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-4-amd64
}
我查看了内核源代码和文档、VirtualBox 文档以及其他地方的各个部分来寻找答案。我尝试过添加和删除mem=16G
、iommu=soft
、swiotlb=force
、allowdac
、noefi
、 的各种组合,但add_efi_memmap
没有任何实际效果。正如预期的那样,该iommu=soft
参数确实消除了与“卡尔加里”相关的消息,但对报告的内存没有影响。只是为了好玩,我尝试将配置的内存减少到 8GB,但这也没有明显的效果。如果重要的话,我正在运行库存内核。
还有什么可能有效?
编辑:
这是输出dmidecode
:
# dmidecode 2.11
# SMBIOS entry point at 0xdfbce000
SMBIOS 2.5 present.
10 structures occupying 449 bytes.
Table at 0xDFBCE020.
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
Vendor: innotek GmbH
Version: VirtualBox
Release Date: 12/01/2006
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 128 kB
Characteristics:
ISA is supported
PCI is supported
Boot from CD is supported
Selectable boot is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: innotek GmbH
Product Name: VirtualBox
Version: 1.2
Serial Number: 0
UUID: 0B1BEC54-20D1-4809-A92D-22EE66339AA8
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Virtual Machine
Handle 0x0008, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Oracle Corporation
Product Name: VirtualBox
Version: 1.2
Serial Number: 0
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
Manufacturer: Oracle Corporation
Type: Other
Lock: Not Present
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
Handle 0x0007, DMI type 126, 42 bytes
Inactive
Handle 0x0005, DMI type 126, 15 bytes
Inactive
Handle 0x0006, DMI type 126, 28 bytes
Inactive
Handle 0x0002, DMI type 11, 7 bytes
OEM Strings
String 1: vboxVer_4.3.10
String 2: vboxRev_93012
Handle 0x0008, DMI type 128, 8 bytes
OEM-specific Type
Header and Data:
80 08 08 00 35 C7 31 00
Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table