diff options
author | Thomas Huth <thuth@redhat.com> | 2017-02-15 10:21:44 +0100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2017-02-22 14:28:53 +1100 |
commit | df58713396f8b2deb923e39c00b10744c5c63909 (patch) | |
tree | cec2364995459c2347a0c57e7f45d1dadb848a53 /hw/ppc/ppc405_uc.c | |
parent | 0a4c774086d2246ca14abc5471bf2173d63a3d65 (diff) | |
download | qemu-df58713396f8b2deb923e39c00b10744c5c63909.zip qemu-df58713396f8b2deb923e39c00b10744c5c63909.tar.gz qemu-df58713396f8b2deb923e39c00b10744c5c63909.tar.bz2 |
hw/ppc/spapr: Check for valid page size when hot plugging memory
On POWER, the valid page sizes that the guest can use are bound
to the CPU and not to the memory region. QEMU already has some
fancy logic to find out the right maximum memory size to tell
it to the guest during boot (see getrampagesize() in the file
target/ppc/kvm.c for more information).
However, once we're booted and the guest is using huge pages
already, it is currently still possible to hot-plug memory regions
that does not support huge pages - which of course does not work
on POWER, since the guest thinks that it is possible to use huge
pages everywhere. The KVM_RUN ioctl will then abort with -EFAULT,
QEMU spills out a not very helpful error message together with
a register dump and the user is annoyed that the VM unexpectedly
died.
To avoid this situation, we should check the page size of hot-plugged
DIMMs to see whether it is possible to use it in the current VM.
If it does not fit, we can print out a better error message and
refuse to add it, so that the VM does not die unexpectely and the
user has a second chance to plug a DIMM with a matching memory
backend instead.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1419466
Signed-off-by: Thomas Huth <thuth@redhat.com>
[dwg: Fix a build error on 32-bit builds with KVM]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'hw/ppc/ppc405_uc.c')
0 files changed, 0 insertions, 0 deletions