spapr: Correct RAM size calculation for HPT resizing

In order to prevent the guest from forcing the allocation of large amounts
of qemu memory (or host kernel memory, in the case of KVM HV), we limit
the size of Hashed Page Table (HPT) it is allowed to allocated, based on
its RAM size.

However, the current calculation is not correct: it only adds up the size
of plugged memory, ignoring the base memory size.  This patch corrects it.

While we're there, use get_plugged_memory_size() instead of directly
calling pc_existing_dimms_capacity().  The only difference is that it
will abort on failure, which is right: a failure here indicates something
wrong within qemu.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
This commit is contained in:
David Gibson 2017-10-11 00:16:57 +11:00
parent beba5c0fe4
commit db50f280cf
1 changed files with 2 additions and 2 deletions

View File

@ -472,7 +472,7 @@ static target_ulong h_resize_hpt_prepare(PowerPCCPU *cpu,
target_ulong flags = args[0];
int shift = args[1];
sPAPRPendingHPT *pending = spapr->pending_hpt;
uint64_t current_ram_size = MACHINE(spapr)->ram_size;
uint64_t current_ram_size;
int rc;
if (spapr->resize_hpt == SPAPR_RESIZE_HPT_DISABLED) {
@ -494,7 +494,7 @@ static target_ulong h_resize_hpt_prepare(PowerPCCPU *cpu,
return H_PARAMETER;
}
current_ram_size = pc_existing_dimms_capacity(&error_fatal);
current_ram_size = MACHINE(spapr)->ram_size + get_plugged_memory_size();
/* We only allow the guest to allocate an HPT one order above what
* we'd normally give them (to stop a small guest claiming a huge