summaryrefslogtreecommitdiff
path: root/tests/qapi-schema
diff options
context:
space:
mode:
authorThomas Huth <thuth@redhat.com>2016-06-22 10:50:05 +0200
committerDavid Gibson <david@gibson.dropbear.id.au>2016-06-23 12:53:42 +1000
commit86b50f2e1befc33407bdfeb6f45f7b0d2439a740 (patch)
tree453b5f7253bf937269ee822b2c92ca4b51eb3d20 /tests/qapi-schema
parent7778a575c7055276afdd01737e9d1029a65f923d (diff)
downloadqemu-86b50f2e1befc33407bdfeb6f45f7b0d2439a740.tar.gz
qemu-86b50f2e1befc33407bdfeb6f45f7b0d2439a740.tar.bz2
qemu-86b50f2e1befc33407bdfeb6f45f7b0d2439a740.zip
ppc: Disable huge page support if it is not available for main RAM
On powerpc, we must only signal huge page support to the guest if all memory areas are capable of supporting huge pages. The commit 2d103aae8765 ("fix hugepage support when using memory-backend-file") already fixed the case when the user specified the mem-path property for NUMA memory nodes instead of using the global "-mem-path" option. However, there is one more case where it currently can go wrong. When specifying additional memory DIMMs without using NUMA, e.g. qemu-system-ppc64 -enable-kvm ... -m 1G,slots=2,maxmem=2G \ -device pc-dimm,id=dimm-mem1,memdev=mem1 -object \ memory-backend-file,policy=default,mem-path=/...,size=1G,id=mem1 the code in getrampagesize() currently assumes that huge pages are possible since they are enabled for the mem1 object. But since the main RAM is not backed by a huge page filesystem, the guest Linux kernel then crashes very quickly after being started. So in case the we've got "normal" memory without NUMA and without the global "-mem-path" option, we must not announce huge pages to the guest. Since this is likely a mis-configuration by the user, also spill out a message in this case. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'tests/qapi-schema')
0 files changed, 0 insertions, 0 deletions