diff options
author | Thomas Huth <thuth@redhat.com> | 2016-06-22 10:50:05 +0200 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2016-06-23 12:53:42 +1000 |
commit | 86b50f2e1befc33407bdfeb6f45f7b0d2439a740 (patch) | |
tree | 453b5f7253bf937269ee822b2c92ca4b51eb3d20 /tests | |
parent | 7778a575c7055276afdd01737e9d1029a65f923d (diff) | |
download | qemu-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')
0 files changed, 0 insertions, 0 deletions