71c2768433
The virt board restricts guests to only 30GB of RAM. This is a hangover from the vexpress-a15 board, and there's no inherent reason for it. 30GB is smaller than you might reasonably want to provision a VM for on a beefy server machine. Raise the limit to 255GB. We choose 255GB because the available space we currently have below the 1TB boundary is up to the 512GB mark, but we don't want to paint ourselves into a corner by assigning it all to RAM. So we make half of it available for RAM, with the 256GB..512GB range available for future non-RAM expansion purposes. If we need to provide more RAM to VMs in the future then we need to: * allocate a second bank of RAM starting at 2TB and working up * fix the DT and ACPI table generation code in QEMU to correctly report two split lumps of RAM to the guest * fix KVM in the host kernel to allow guests with >40 bit address spaces The last of these is obviously the trickiest, but it seems reasonable to assume that anybody configuring a VM with a quarter of a terabyte of RAM will be doing it on a host with more than a terabyte of physical address space. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Tested-by: Wei Huang <wei@redhat.com> Message-id: 1456402182-11651-1-git-send-email-peter.maydell@linaro.org |
||
---|---|---|
.. | ||
9pfs | ||
acpi | ||
alpha | ||
arm | ||
audio | ||
block | ||
bt | ||
char | ||
core | ||
cpu | ||
cris | ||
display | ||
dma | ||
gpio | ||
i2c | ||
i386 | ||
ide | ||
input | ||
intc | ||
ipack | ||
ipmi | ||
isa | ||
lm32 | ||
m68k | ||
mem | ||
microblaze | ||
mips | ||
misc | ||
moxie | ||
net | ||
nvram | ||
openrisc | ||
pci | ||
pci-bridge | ||
pci-host | ||
pcmcia | ||
ppc | ||
s390x | ||
scsi | ||
sd | ||
sh4 | ||
smbios | ||
sparc | ||
sparc64 | ||
ssi | ||
timer | ||
tpm | ||
tricore | ||
unicore32 | ||
usb | ||
vfio | ||
virtio | ||
watchdog | ||
xen | ||
xenpv | ||
xtensa | ||
Makefile.objs |